Adilton Ribeiro de Souza

Aline Lima Viana

Lucinaldo Araújo Maciel

Rodrigo Garcia Barbosa

Wládia Karina Damasceno Silva

DESAFIOS NO GERENCIAMENTO DE PROJETOS

DISTRIBUÍDOS GEOGRAFICAMENTE EM UMA EMPRESA
PÚBLICA DE TECNOLOGIA DE INFORMAÇÃO.

Trabalho apresentado ao curso MBA em

Gerenciamento de Projetos, Pós-
Graduação lato sensu, Nível de
Especialização, do Programa FGV
Management da Fundação Getulio Vargas,
como pré-requisito para a obtenção do
Titulo de Especialista.

CARLOS A. C. SALLES JR.

MÁRIO LUIS SAMPAIO PEREIRA

Fortaleza – CE

2011
FUNDAÇÃO GETULIO VARGAS

PROGRAMA FGV MANAGEMENT

MBA EM GERÊNCIAMENTO DE PROJETOS

O Trabalho de Conclusão de Curso “Desafios no gerenciamento de projetos

distribuídos geograficamente em uma empresa pública de tecnologia de
informação”, elaborado por Adilton Ribeiro de Souza, Aline Lima Viana, Lucinaldo
Araújo Maciel, Rodrigo Garcia Barbosa, Wládia Karina Damasceno Silva e aprovado
pela Coordenação Acadêmica, foi aceito como pré-requisito para a obtenção do
certificado do Curso de Pós-Graduação lato sensu MBA em Gerenciamento de
Projetos, Nível de Especialização, do Programa FGV Management.

Data da Aprovação: Fortaleza, 27 de Julho de 2011

Carlos A. C. Salles Jr.

Coordenador Acadêmico Executivo

Mário Luis Sampaio Pereira

Orientador
 TERMO DE COMPROMISSO

Os alunos Adilton Ribeiro de Souza, Aline Lima Viana, Lucinaldo Araújo Maciel,
Rodrigo Garcia Barbosa e Wládia Karina Damasceno Silva, abaixo assinados, do
curso de MBA em Gerenciamento de Projetos, Turma GP05, do Programa FGV
Management, realizado nas dependências da instituição conveniada MRH, no
período de 18/06/2009 a 27/07/2011, declara que o conteúdo do Trabalho de
Conclusão de Curso intitulado “Desafios no gerenciamento de projetos
distribuídos geograficamente em uma empresa pública de tecnologia de
informação”, é autêntico e original.

Fortaleza, 27 de Julho de 2011

Adilton Ribeiro de Souza

Aline Lima Viana

Lucinaldo Araújo Maciel

Rodrigo Garcia Barbosa

Wládia Karina Damasceno Silva

 Dedicatória

Dedicamos este trabalho aos nossos pais, esposos e esposas e nossos filhos
pela paciência e tolerância em suportar nossas ausências quando estávamos
assistindo as aulas, fazendo as provas e dedicando tempo e esforço no estudo das
disciplinas e na elaborando desta monografia.
 Resumo

O cenário público brasileiro hoje beneficiado pela atenção prioritária de seus

governantes, aliado a uma extrema necessidade de avanço tecnológico de seus
sistemas, têm provocado inúmeros incentivos financeiros visando uma renovação
tecnológica de suas ferramentas de trabalho. Tais ações têm como objetivo
fundamental a busca do melhor atendimento ao cidadão brasileiro. Dentro deste
cenário, várias empresas públicas recebem uma grande quantidade de demandas
relativas a essa reestruturação dos sistemas públicos. Sejam para si próprias, ou
para outras a quem prestam serviços. Para o atendimento destas demandas, torna-
se necessário a criação de projetos, ou programas, embasando-se no conceito de
dividir para conquistar. Para todo e qualquer projeto, que possui como
características essenciais um prazo determinado e objetivos definidos, almeja-se
sempre a obtenção do sucesso na conquista destes objetivos. Nada mais necessário
que a gerência de projeto, que visa a aplicação de conhecimentos, habilidades e
técnicas na elaboração de atividades pré-planejadas, sendo fator determinante para
a obtenção deste sucesso. Tendo como objetivo principal do projeto o
desenvolvimento de software, o qual reúne atividades bem específicas da área de
tecnologia, têm-se nos dias atuais a facilidade do trabalho distribuído, no qual não é
necessário que toda a equipe concentre-se em um mesmo ambiente, cidade ou
Estado. Tomando como exemplo uma destas empresas públicas, distribuída por
todo o Brasil, que têm como uma de suas atividades atuais o desenvolvimento de
um sistema de gestão de benefícios sociais, centrado em um Programa,
identificamos aqui um objeto de estudo que trará uma série de dificuldades na sua
realização. Este trabalho se propõe a estudar o contexto e a problemática deste
Programa, tendo como meta a identificação e análise dos problemas encontrados.
Como contribuição, ao resultado final do estudo elencaremos boas práticas a serem
tomadas, a nível da gestão de projetos, os quais possuam características
semelhantes com o aqui apresentado.

Palavras Chave: Gerenciamento de projetos, desenvolvimento de software,

desenvolvimento distribuído, sucesso em projetos, setor público.
 Abstract

The currently Brazilian public scenario is benefited by the priority attention of

its governments associated to an extreme necessity of technological advance in their
systems has caused several financial incentives picturing a technological renew in
their work tools. Such actions aim to search a better attendance to the Brazilian
citizens. Covered by this scenario, many Public Companies receive a huge quantity
of demands related to this restructuration about the public system. As for itself as for
another which it serves. Aiming to attend this demands, it becomes necessary to
create projects or programs based on the concept of “divide to conquer”. For any
project which is characterized by an essential determined finishing schedule and
defined objectives, it is always fundamental to obtain the success in its objectives.
Nothing is more important than a project management which aims to apply
knowledge, ability and techniques to elaborate pre planned activities, as an essential
factor for this success. As the main project objective is the software development,
which covers well specified activities from technological area, we have in usual days
the facility of the distributed work. In distributed work is not necessary the entire team
into the same environment, city or state. Taking as example one public company
distributed all around Brazil, which has as current activity the software development
of a social benefits management system, centered in a Program, we identify a study
object that bring us several difficulties in its implementation. This work is proposed to
study the context and the problematic of this Program, and aims to identify and
analyze the problems caused. As contribution, in the end of the study, we associate
good practices to be applied, in level of project management, which has similar
characteristics to the ones presented here.

Key Words: Project management, software development, distributed

development, project success, the public sector.
 Agradecimentos

Agradeço a Deus que nos deu tudo, o dom da vida, a sabedoria e a coragem
para trilharmos nossos caminhos.

Agradeço aos meus pais, meus primeiros mestres, que nos ensinaram os
passos para a retidão de caráter.

Agradeço aos professores da FGV, que com sua paciência, nos ensinaram
muito além do conteúdo das disciplinas quando nos mostraram o poder do processo
de aprendizado e a importância dos fatores humanos na condução das nossas
carreiras profissionais.

Agradeço aos colegas de classe, pelo convívio fraternal e por compartilhar

conosco suas experiências de vida, tornando o conhecimento mais rico.

Agradeço à empresa em que trabalho pelo apoio e condições propiciados para

que fosse possível tornar este projeto realidade.
SUMÁRIO

1. INTRODUÇÃO ...................................................................................................... 11
1.1 Relevância do Trabalho/Justificativa ............................................................... 12
1.2 Objetivos ......................................................................................................... 13
1.3 Metodologia Científica ..................................................................................... 13
2. FUNDAMENTAÇÃO TEÓRICA ............................................................................. 15
2.1 Sucesso em Gerenciamento de Projetos de TI com o PMBOK. ..................... 15
2.1.1. Sucesso em Projetos ............................................................................ 16
2.1.2. Maturidade e Excelência no Gerenciamento de Projetos ..................... 17
2.1.3. PMBOK ................................................................................................. 18
2.2 Organizações Públicas e o Gerenciamento de Projetos de TI ........................ 20
2.2.1. O papel da TI nas organizações públicas ............................................. 21
2.2.2. Gerenciamento de Projetos no Setor Público ....................................... 22
2.3. Desenvolvimento Distribuído de Software (DDS) ........................................... 23
2.3.1. Níveis de Dispersão e Modelos de Negócio ......................................... 25
2.4. O PMBOK aplicado ao DDS em organizações públicas ................................ 27
2.4.1. Gerenciamento da Integração .............................................................. 27
2.4.2. Gerenciamento das Comunicações ...................................................... 29
2.4.3. Gerenciamento do Escopo ................................................................... 31
2.4.4. Gerenciamento de Riscos ..................................................................... 32
2.4.5. Gerenciamento da Qualidade ............................................................... 34
2.4.6. Gerenciamento do Tempo .................................................................... 36
2.4.7. Gerenciamento dos Custos .................................................................. 37
2.4.8. Gerenciamento das Aquisições ............................................................ 38
2.4.9. Gerenciamento dos Recursos Humanos .............................................. 39
3. CONTEXTO DA ANÁLISE .................................................................................... 41
3.1 A Empresa ...................................................................................................... 41
3.2 O Programa..................................................................................................... 42
4. ANÁLISE CRÍTICA DO PROGRAMA .................................................................... 45
4.1 Qualidade ........................................................................................................ 45
4.2 Recursos Humanos ......................................................................................... 48
4.3 Risco..... .......................................................................................................... 51
 4.4 Integração ....................................................................................................... 54
4.5 Comunicação .................................................................................................. 56
4.6 Tempo.. ........................................................................................................... 58
4.7 Escopo.. .......................................................................................................... 60
5. PESQUISA. ........................................................................................................... 62
5.1 Contextualização ............................................................................................. 62
5.2 Universo amostral e amostra .......................................................................... 63
5.3 Formatação da Pesquisa ................................................................................ 63
5.4 Definindo questionários de maturidade personalizado .................................... 64
5.5 Limitações ....................................................................................................... 65
5.6 Análise dos resultados .................................................................................... 66
5.6.1 Técnica de análise e interpretação de dados ........................................ 66
5.6.2 Análise dos questionários ...................................................................... 66
5.6.3 Questionário sobre a maturidade da empresa ....................................... 67
5.6.3.1 Quesitos com destaque positivo (Alta maturidade) ...................... 67
5.6.3.2 Quesitos a serem desenvolvidos (Baixa maturidade) ................... 70
5.6.4 Questionário sobre a maturidade dos gestores ..................................... 73
5.6.4.1 Quesitos com destaque positivo (Alta maturidade) ...................... 73
5.6.4.2 Quesitos a serem desenvolvidos (Baixa maturidade) ................... 74
6. CONCLUSÕES ........................................................ Erro! Indicador não definido.
7. POSSÍVEIS DESDOBRAMENTOS ..................................................................... 118
8. REFERÊNCIAS BIBLIOGRÁFICAS .................................................................... 119
9. GLOSSÁRIO ....................................................................................................... 124
10. APÊNDICES...................................................................................................... 125
10.1 Apêndice 1 .................................................................................................. 125
10.2 Apêndice 2 .................................................................................................. 127
 LISTA DE FIGURAS E TABELAS

Figura 2.1 – Interação entre os grupos de processos do PMBOK ..........................17

Figura 2.2 – Principais desafios no DDS .................................................................24

Figura 3.1 – Organograma da Diretoria de Desenvolvimento de Produtos e Soluções

................................................................................................................................41

Figura 3.2 – Distribuição física do cliente e unidades de desenvolvimento do

programa .................................................................................................................43

Figura 5.1 – Níveis de Maturidade do P3M3 ...........................................................63

Figura 5.2 – Distribuição da maturidade da EAP e declaração de escopo ..............68

Figura 5.3 – Distribuição dos níveis de alocação da equipe em tempo integral ......69

Figura 5.4 – Distribuição dos níveis de maturidade pra aprovação prévia das
alterações nas linhas de base dos projetos. ...........................................................71
 11

1. INTRODUÇÃO

Gerenciar um projeto de desenvolvimento de software, de forma geral, já é

um grande desafio. Normalmente, envolve o controle das mudanças nos requisitos
(principalmente após o fim da fase de especificação), o desenvolvimento do sistema
com uma tecnologia que atenda as necessidades das partes envolvidas (cliente,
desenvolvedor, suporte...), as baterias de testes funcionais, entre diversas outras
atividades.

Quando nos voltamos para o gerenciamento deste tipo de projeto em uma

empresa pública de tecnologia da informação e comunicação (TIC), esta tarefa
adquire uma complexidade maior. O gerente de projeto precisa estar ciente das
limitações que cercam o projeto, como limitações de aquisição e de custos, e do
processo de desenvolvimento da empresa, que pode vir a ser bastante moroso e
burocrático.

A necessidade da interação com sistemas corporativos já existentes também

é um ponto a ser considerado neste caso. A integração com estes sistemas deve ser
planejada cuidadosamente, uma vez que eles já estão funcionais e em plena
utilização. Além disso, a tecnologia utilizada para estes sistemas pode estar
obsoleta, comprometendo ou dificultando ainda mais esta integração.

Ao se somar estes e outros fatores com o fato da empresa possuir várias

unidades de desenvolvimento distribuídas geograficamente no território Brasileiro,
tornamos o gerenciamento desse tipo de projeto ainda mais complexo, sendo estes
projetos sensíveis a um número incrivelmente alto de riscos e dificuldades.

O presente trabalho tem por objetivo identificar e analisar as dificuldades e

problemas na gerência de projetos distribuídos, realizadas por empresas públicas de
tecnologia de informação. Para o estudo de caso adotamos uma empresa do setor
público que possui unidades distribuídas pelo país e que tem como uma de suas
atividades o desenvolvimento de software. O trabalho baseou-se em uma análise
conceitual de um programa de desenvolvimento de um software real que se encontra
em pleno desenvolvimento.

O trabalho foi estruturado da seguinte forma: No segundo capítulo é

apresentada a fundamentação teórica, elemento necessário para a compreensão e
 12

desenvolvimento do trabalho. O capítulo possui quatro seções, as quais discorrem

respectivamente sobre conceitos de gerenciamento de projetos e teorias de sucesso
nos mesmos, organizações do setor público e seus projetos, conceitos de
desenvolvimento distribuídos de software e aplicação de boas práticas do PMBOK
em desenvolvimento de software distribuído.

O terceiro capítulo contextualiza a situação atual da empresa estudada e do

programa utilizado na análise. No capítulo seguinte, o quarto, são elencados os
problemas e dificuldades observadas pelos autores, tomando como guia as áreas de
conhecimento listadas pelo PMBOK.

O quinto capítulo abordará a pesquisa aplicada aos gerentes de projeto

empregados na empresa escolhida para estudo do caso, como também a análise
dos resultados obtidos.

No capítulo seis são listadas as conclusões dos autores baseadas no trabalho

desenvolvido propondo boas práticas beneficentes a projetos que possuam
características similares ao tratado no estudo.

Finalmente o sexto capítulo descreve os possíveis desdobramentos que

poderão ser tomados com o estudo do trabalho elaborado.

1.1 Relevância do Trabalho/Justificativa

Tendo em vista a dificuldade de construir distribuidamente um software com

sucesso, é preciso organizar, planejar, controlar e integrar a construção do sistema
para que se consiga um resultado positivo ao final do projeto. Aliado ao fato deste
software possuir como executor uma empresa pública, o que traz como bagagem
junto às dificuldades já existentes o fator burocracia e as limitações e decisões
tomadas por questões políticas, entramos em um tema interessante e de pouco
estudo. A essa falta de informações e conhecimentos do tema escolhido, junto ao
fato de estar participando de um programa com tais características, tomei isso como
motivação para a realização de um trabalho científico de identificação e análise das
dificuldades encontradas na gerência dos projetos em questão, culminando em
propostas de boas práticas a serem adotadas quando da realização de projetos
semelhantes.
 13

1.2 Objetivos

Este trabalho tem como objetivo identificar e analisar potenciais dificuldades e

problemas no gerenciamento de projetos distribuídos geograficamente e realizados
por empresas públicas de tecnologia da informação e comunicação (TIC), no âmbito
das áreas de conhecimento consideradas pelo PMBOK.
Além do objetivo geral, serão abordados os seguintes objetivos específicos:
 Discorrer sobre os fatores que caracterizam um projeto de sucesso;

 Diagnosticar as dificuldades que possam ter impacto no desenvolvimento

de projetos de sucesso, com base na situação a ser analisada proposta no
estudo de caso.

 Mapear as dificuldades encontradas em projetos com as características de

desenvolvimento de software distribuídos em uma empresa pública,
classificando-as nas respectivas áreas de conhecimento do gerenciamento
de projetos definidas pelo PMBOK;

 Aplicar pesquisa em uma empresa selecionada para obtenção de níveis

de maturidade do processo da mesma como também do conhecimento
dos gestores atuantes;

 Analisar os resultados obtidos na pesquisa de forma a confrontar com os

diagnósticos anteriormente elencados;

 Propor soluções que beneficiem a gestão de projetos distribuídos

geograficamente em uma empresa pública de TIC, possibilitando que a
gestão seja mais eficiente e que consiga conduzir o projeto de forma a
torná-lo um projeto de sucesso.

1.3 Metodologia Científica

A metodologia utilizada é a pesquisa aplicada, como forma de diagnosticar

todos os desafios e problemas enfrentados no gerenciamento de projetos de TIC,
mais especificamente em um programa geograficamente distribuído da empresa
pública XYZ. A intenção da pesquisa é confrontar a visão dos autores, os quais
estão vivenciando a experiência de trabalhar no programa que é objeto do estudo de
 14

caso, com o resultado obtido na pesquisa, e assim estabelecer um direcionamento

dos problemas que precisam ser investigados.

O mecanismo de coleta de dados utilizado foi a pesquisa de campo, com

ênfase na utilização de questionários. A pesquisa teve como público alvo os
gestores atuantes nos projetos do programa em questão da empresa. Ao fim da
análise consolidada sugerimos boas práticas e melhorias no processo de gerência
da empresa com base no PMBOK, à luz de abordagens de gerenciamento de
projetos de software (tais como CMMI e RUP) e fomentadas com experiências reais
vivenciadas pelos autores.

Seguindo orientações internas da empresa foco do estudo de caso, foi

necessário preservar o anonimato de sua razão social, departamentos, Programa, e
toda e qualquer identificação própria. Assim sendo, serão utilizadas descrições
fictícias para nomear as entidades referenciadas ao longo dos capítulos.

Devido ao fato do programa, objeto do estudo, estar em sua plena execução,

houve uma grande dificuldade na aplicação dos questionários e sua consequente
coleta dos dados. Apesar da elaboração e aplicação da pesquisa ter sido realizada
em formato acessível remotamente, a extensão dos questionários não permitiu que
os mesmos fossem disponibilizados sem uma prévia explanação presencial do seu
conteúdo e modo de preenchimento. Pelos motivos apresentados decidiu-se aplicar
a pesquisa apenas em uma das unidades de desenvolvimento da empresa, a qual
teve uma boa representatividade com a amostra escolhida.

Pelo motivo do andamento do projeto já estar avançado, não existe tempo

hábil para aplicação de qualquer estratégia de melhoria proposta pelos autores.
Portanto, fica evidente a impossibilidade de proceder qualquer comparativo entre os
resultados obtidos com o citado programa e algum outro de características similares
que faça uso das propostas de soluções indicadas.
 15

2. FUNDAMENTAÇÃO TEÓRICA

Este capítulo tem como objetivo a apresentação de definições e conceitos

existentes na literatura e que foram considerados relevantes para a compreensão e
o desenvolvimento do presente trabalho.

A primeira seção deste capítulo apresenta os conceitos referentes ao

gerenciamento de projetos de tecnologia da informação, o PMBOK e teorias sobre o
alcance do sucesso em projetos. A segunda seção vai descrever as organizações do
setor público e o gerenciamento de projetos nas mesmas. Na terceira seção, será
apresentado o conceito de desenvolvimento distribuído de software (DDS). Por fim, a
quarta seção compreende as ideias de aplicação das boas práticas do PMBOK no
âmbito do desenvolvimento distribuído de software.

2.1 Sucesso em Gerenciamento de Projetos de TI com o PMBOK.

Atualmente, a sobrevivência e o crescimento das organizações têm

dependido, cada vez mais, de sua habilidade em entender o mercado e desenvolver
e implementar um eficiente planejamento estratégico (PRADO, 2007). Segundo o
PMI (2008), os projetos são amplamente utilizados como forma de atingir o plano
estratégico de uma organização. Os projetos são autorizados como resultado de
uma ou mais das seguintes considerações estratégicas: a) demanda de mercado; b)
oportunidade / necessidade estratégica de negócios; c) solicitação de cliente; d)
avanço tecnológico; e) requisito legal.

Ainda de acordo com o PMI (2008, p. 12), um projeto “é um esforço

temporário empreendido para criar um produto, serviço ou resultado exclusivo”.
Kerzner (2002) acrescenta, ainda, que este esforço “consome recursos e opera sob
pressões de custos, prazos e qualidade”.

Segundo o IBGE – Instituto Brasileiro de Geografia e Estatística (2011), as

tecnologias da informação (TI), vêm assumindo um papel estratégico crescente, na
medida em que a participação dos agentes econômicos em mercados altamente
competitivos depende do uso cada vez mais intensivo dessas ferramentas
tecnológicas. A rapidez no acesso das informações e a eficiência no domínio das
 16

tecnologias que as envolvem tornam-se um diferencial em termos de vantagens

competitivas.

Dentre os principais produtos de uma organização de TI está o

desenvolvimento de software. Segundo pesquisa realizada pelo IBGE no setor de TI
em 2009, o desenvolvimento de software (próprio ou customizado) responde por
28,9% da receita bruta das organizações da área de TI.

Pressman (2006) apud Leme (2010), diz que todo projeto de software é
iniciado por alguma necessidade do negócio de uma organização, o que traz a
motivação para que o desenvolvimento do software seja cada vez mais integrado à
organização e seus processos. Ainda segundo Pressman, a utilização de processos
bem definidos de engenharia, bem como de ferramentas de desenvolvimento, são
os melhores recursos para se obter software de qualidade, num intervalo de tempo
curto e com menores custos. Com base nisto, o gerenciamento de projetos tem uma
função muito importante nos projetos de software.

O gerenciamento de projetos consiste na aplicação de conhecimento, de

habilidades, de ferramentas e técnicas a uma ampla gama de atividades para
atender aos requisitos de um determinado projeto (PMI, 2008). Esta abordagem vem
se tornando uma tendência entre as organizações modernas, pois os clientes
apresentam necessidades cada vez mais complexas, demandando rapidez e
agilidade e exigindo qualidade dos produtos e serviços (COSTA, 2010).

Dentre os benefícios do gerenciamento de projetos, Maciel (2010) enumera:

a) aumento da lucratividade em longo prazo; b) facilidade na identificação de
problemas e suas soluções; c) maior qualidade dos produtos e serviços entregues;
d) ganhos de eficiência organizacional a longo prazo; e) gestão mais adequada de
recursos. Além disso, o PMI (2007) afirma que um gerenciamento de projetos eficaz
é essencial para a conversão das estratégias de negócios em resultados positivos
de negócios.

2.1.1. Sucesso em Projetos

Antes de discutirmos o papel das boas práticas no sucesso do gerenciamento

de projetos, é necessário explicitar que a medição do sucesso em projetos não é
uma tarefa simples e a sua definição é bastante relativa. A noção de sucesso pode
 17

variar de acordo com o tempo e o momento em que o projeto está sendo analisado e
de acordo com quem está analisando o projeto (BARCAUI, 2011). Segundo Passos
(2008) apud Maciel (2010), os conceitos de sucesso e fracasso podem ser diferentes
para os interessados nos projetos, causando ambiguidade e dificultando sua
definição.

Kerzner (2002) explica que, basicamente, o gerenciamento de um projeto terá

sido bem sucedido se os objetivos do mesmo foram atingidos: a) dentro do prazo; b)
no orçamento previsto; c) com os critérios desejados de qualidade; d) com uso eficaz
e eficiente dos recursos; e) com aceitação por parte do cliente. No entanto, “a
definição de sucesso também pode variar dependendo de tratar-se ou não de
empresas orientadas a projetos” (KERZNER, 2002, p. 45). Para empresas
orientadas a projetos, o foco do negócio são os projetos. Em empresas não
orientadas a projetos, eles só existem para sustentar a atividade atual de produção
ou serviços. Nesse tipo de empresa, a definição de sucesso também inclui concluir o
projeto no prazo, sem causar problemas às atividades principais da organização.

Mais especificamente falando sobre projetos de software, a definição de

sucesso de Krigsman (2011) inclui que o software produzido pelo projeto deve ser
adotado pelo usuário para o qual foi desenvolvido. Isto envolve projetar um software
que se encaixe nos fluxos de trabalho atuais da organização do usuário e que
proporcione uma boa experiência durante seu uso, de forma a reduzir os obstáculos
para sua adoção.

Embora não exista um consenso acerca do conceito de sucesso, diversos

autores afirmam que a utilização de boas práticas pode influenciar positivamente o
gerenciamento de projetos.

2.1.2. Maturidade e Excelência no Gerenciamento de Projetos

Segundo Kerzner (2002), a maturidade em gerenciamento de projetos

corresponde ao desenvolvimento de sistemas e processos de natureza repetitiva,
garantindo uma maior probabilidade de que cada um deles obtenha sucesso. Porém,
uma organização pode ser madura no gerenciamento de projetos e não ser
excelente. Por sua vez, organizações com excelência no gerenciamento de projetos
criam um ambiente em que existe um fluxo contínuo de projetos gerenciados com
 18

sucesso, mensurado tanto pelo alcance do desempenho em pontos estratégicos

como um todo como pela conclusão de um projeto específico (KERZNER, 2002). A
excelência vai além da maturidade, mas é necessário ter maturidade para se atingir
a excelência (KERZNER, 2003).

Apesar de ser uma discussão relativamente recente, já existem diversos

modelos voltados para o crescimento da maturidade, reconhecidos e utilizados
mundialmente, que podem ser utilizados pelas organizações para a identificação de
seu grau de maturidade no gerenciamento de projetos, permitindo, principalmente, o
planejamento de melhorias contínuas e sistemáticas para a organização. Não existe
um consenso sobre qual modelo de maturidade é mais apropriado, pois os modelos
têm propostas e abordagens diferentes (CARNEIRO, 2010).

A partir de uma pesquisa sobre maturidade em gerenciamento de projetos

realizada em 2010, Prado (2011) afirma que existe uma relação positiva entre
sucesso e maturidade: quanto maior a maturidade, maior o sucesso.

Kerzner (2002) aponta que o estabelecimento de uma metodologia de gestão

de projetos é muito importante para o alcance da maturidade. Embora a existência
da mesma não seja garantia de sucesso e excelência, uma boa metodologia deve
melhorar o desempenho durante a execução do projeto, criando também condições
para aumentar a confiança dos stakeholders e, assim, aperfeiçoar o relacionamento
com eles. O autor ainda recomenda que a metodologia não seja desenvolvida a
partir do zero.

2.1.3. PMBOK

Existem inúmeras abordagens, métodos e atividades que as organizações

podem adotar para aumentar as chances de sucesso no gerenciamento de seus
projetos. O PMI (2008) afirma que a crescente aceitação do gerenciamento de
projetos indica que a aplicação de conhecimentos, processos, habilidades,
ferramentas e técnicas adequadas pode causar um impacto significativo no sucesso
de um projeto.

Souza e Ferreira (2006) afirmam que a adoção das boas práticas na gerência
de projetos é um fator crítico de sucesso para a sobrevivência dos departamentos de
tecnologia de informação das organizações. As autoras dizem que é necessária uma
 19

abordagem estruturada para o gerenciamento de projetos, sobretudo em projetos de

software, cujo escopo não é bem definido e não segue uma tendência constante
durante o seu desenvolvimento.

O PMBOK é um guia que busca identificar um conjunto de boas práticas em

gerenciamento de projetos, que possa ser aplicável para aumentar as possibilidades
de sucesso em uma ampla gama de projetos (PMI, 2008). Ou seja, incluem-se aqui
os projetos de software. Além disso, este guia fornece e promove um vocabulário
comum para a profissão e a prática de gerenciamento de projetos.

Figura 2.1 – Interação entre os grupos de processos do PMBOK, adaptado de PMI (2008).

O guia PMBOK é compilado pelo PMI, a partir de um processo voluntário de

desenvolvimento de normas de consenso. Em sua 4ª. edição, o guia enumera 42
processos para o gerenciamento de projetos, os quais serão descritos
posteriormente neste capítulo. Embora sejam apresentados como elementos
distintos, os processos de gerenciamento de projetos se sobrepõem e interagem
entre si no decorrer do projeto. A figura 2.1 demonstra como funciona esta
integração entre os grupos de processos. É possível notar que os processos de
monitoramento e controle, por exemplo, interagem com os outros grupos de
processos.

No entanto, de acordo com próprio guia, os processos descritos não precisam

ser aplicados de forma uniforme em todos os projetos. Em qualquer projeto
 20

específico, o gerente de projetos e sua equipe devem determinar quais processos

são apropriados e adequá-los.

2.2 Organizações Públicas e o Gerenciamento de Projetos de TI

As organizações públicas têm como objetivo a prestação de serviços para a

sociedade e se apresentam como sistemas dinâmicos, complexos, interdependentes
e inter-relacionados, envolvendo estruturas organizacionais, pessoas, tecnologias,
informações e seus fluxos (PIRES e MACÊDO, 2006).

Carneiro (2010) aponta que, ao contrário das organizações privadas, as

organizações públicas não buscam o lucro e sim o atendimento a interesses
coletivos. Outra característica bastante relevante que difere a administração pública
da privada é a necessidade da existência de leis que regulem e permitam as ações
por parte da administração pública. Segundo Ortolani (1997) apud Tait (2000), na
iniciativa pública só é possível fazer o que está previsto na legislação, ao passo que
na iniciativa privada é permitido fazer tudo o que não está proibido pela legislação.

Pires e Macêdo (2006) fazem um levantamento de diversas características do

setor público: a) burocratismo; b) autoritarismo / centralização; c) paternalismo; d)
ausência de empreendedorismo; e) vulnerabilidade a interferências políticas; f)
descontinuidade administrativa. Martelane (1991) apud Pires e Macêdo (2006)
aponta a existência de dois corpos funcionais: um permanente e o não-permanente.
O corpo permanente é constituído por trabalhadores de carreira, cuja cultura e
objetivos foram formados na organização, enquanto o corpo não-permanente é
composto por dirigentes políticos, que seguem objetivos externos e mais amplos aos
da organização.

Embora existam características particulares que permitam a diferenciação

entre as organizações do setor público e as do setor privado, Ansoff (1990) apud
Tait (2000), afirma que a distinção está se tornando cada vez mais vaga. É possível
encontrar estruturas burocráticas em organizações privadas e, assim como estas, as
organizações públicas estão buscando a eficiência.
 21

2.2.1. O papel da TI nas organizações públicas

De acordo com Carneiro (2010), para fazer jus às demandas de excelência,

transparência e participação por parte da sociedade, são necessárias políticas
inovadoras de gestão que aumentem e fortaleçam as capacidades institucionais. A
necessidade do Estado apresentar mais eficiência na prestação dos serviços
públicos, aproximar-se do cidadão, aperfeiçoar o monitoramento das aplicações dos
recursos públicos e atender as demandas da população com mais qualidade
impulsionou os governos a pensarem na tecnologia da informação como uma
importante estratégia neste sentido (LOPES, 2009).

A gestão pública brasileira passou por 3 reformas administrativas, sendo a

última delas em 1995, no governo Fernando Henrique Cardoso. O foco das reformas
foi a transformação da administração pública de um caráter burocrático para
gerencial, introduzindo mecanismos de responsabilização social e dando maior
autonomia para as agências governamentais. Em 1995, o “Plano Diretor da Reforma
do Aparelho do Estado”, procurou enfatizar a utilização das tecnologias de
informação como mecanismo impulsionador das reformas da gestão pública
(JUNQUEIRA, 2007).

Tait et al (1999) afirma que o processo de informatização do setor público

brasileiro alavanca dois aspectos: interno, de atendimento aos serviços que
sustentam as atividades da organização pública e o externo, focado no atendimento
ao público. No caso do aspecto interno, temos os sistemas de informação para apoio
ao processo decisório e para integrar todas as áreas do governo. São voltados para
a realização de tarefas rotineiras e, embora já exista uma estruturação destes
sistemas em redes de microcomputadores, a maioria dos sistemas continua sendo
processado em equipamentos mainframe, devido a restrições orçamentárias, que
impedem o avanço na modernização dos serviços de informática. No aspecto
externo, temos o conceito de “governo eletrônico”, ou e-Government, que se propõe
a disponibilizar as informações ao cidadão, agilizando os processos de atendimento
ao público.

É importante observar, no entanto, que a TI isoladamente não é provedora de

mudanças em organizações. As tecnologias por si só não provêm as mudanças se
estas não forem absorvidas pela estrutura organizacional, representada
 22

principalmente pelos processos e pessoas que compõem a organização pública

(JUNQUEIRA, 2007).

2.2.2. Gerenciamento de Projetos no Setor Público

O setor público é, senão o maior, um dos maiores demandantes de projetos,

tanto em quantidade como em volume financeiro (CARNEIRO, 2010). Rosa (2011)
lista as principais diferenças entre os projetos do setor público e os do setor privado,
destacando a importância do conhecimento das mesmas para o êxito no
gerenciamento desse tipo de projeto:

a) Critérios de seleção: os projetos do setor público são iniciados

principalmente para atender a necessidades socioeconômicas e
ambientais, assim como necessidades de saúde, segurança e bem-estar.
Desta forma, caracterizam-se como projetos não lucrativos e de cunho
predominantemente social.

b) Orçamento restrito: o planejamento se pauta pelo ciclo anual de governo.

O orçamento normalmente é alocado para um ano fiscal, obrigando a
divisão de projetos e programas em módulos de um ano. Atrasos nos
projetos podem provocar a perda de recursos, caso haja a prolongação
para o ano posterior.

c) Forte influência política: sofrem grande influência do ciclo eleitoral, não

somente pela possibilidade de alteração de políticas em caso de mudança
na administração, como também por restrições legais estabelecidas pelo
princípio da neutralidade, em período eleitoral.

d) Forte regulamentação: os projetos do setor público são objeto de intensa

regulamentação nas aquisições do governo, pela necessidade de
assegurar igualdade de oportunidade para licitantes de obras e serviços
públicos, bem como garantir a probidade do órgão adquirente.

Willcocks (1994) apud Tait (2000), diz que os projetos no setor público
normalmente são de maior escala que no setor privado, podendo atingir tanto o
público em geral como uma população regional mais específica. Carneiro (2010)
amplia este pensamento afirmando que não seria “estranho se pensarmos que os
maiores projetos da humanidade são, em sua maioria, do setor público”.
 23

Ainda de acordo com Carneiro (2010), a tendência do setor público é a

utilização das práticas administrativas utilizadas no setor privado. Mais
precisamente, o setor público se espelha nas práticas que busquem o aumento de
eficiência, para a melhoria dos serviços prestados. Aqui, incluem-se as boas práticas
de gerenciamento de projetos. A autora argumenta que o gerenciamento de projetos
vem sendo cada vez mais utilizado como “instrumento de gestão para o alcance das
estratégias governamentais”.

Jaques (2011) afirma que o gerenciamento de projetos oferece meios para

lidar com as dificuldades inerentes ao setor público, pois: a) fornece um ambiente
apropriado para a mudança, quando existe esse desejo por parte da administração;
b) oferece formas rápidas de ampliar a compreensão e facilitar a resolução de
problemas; c) provê um melhor gerenciamento de stakeholders, de forma
sistemática.

2.3. Desenvolvimento Distribuído de Software (DDS)

A globalização da economia levou diversas organizações a distribuir

geograficamente seus recursos e investimentos com o intuito de obter melhores
resultados (ZANONI e AUDY, 2003). Audy e Prikladnicki (2007) afirmam que,
especificamente na área de desenvolvimento de software, mercados nacionais têm
se transformado em mercados globais, criando novas formas de cooperação e
competição que ultrapassam as barreiras entre os países. Em busca de vantagem
competitiva, várias organizações optaram pela distribuição do processo de
desenvolvimento de software, caracterizando, desta forma, o Desenvolvimento
Distribuído de Software (HUZITA et al, 2008 apud LEAL, 2010).

Segundo Carmel (1999) apud Costa (2010), as principais características que

diferenciam o desenvolvimento co-localizado do desenvolvimento distribuído são a
distância (distância entre desenvolvedores e distância entre desenvolvedores e
clientes) e as diferenças de fuso horário e culturais (língua, tradições, costumes,
comportamentos, normas). De acordo com Costa (2010), o conceito de distância
possui um conceito mais amplo, podendo ser expandida nos seguintes tipos:
distância temporal, distância cultural, distância organizacional e distância dos
stakeholders.
 24

Audy e Prikladnicki (2007) enumeram alguns fatores que levam as

organizações a adotar o DDS: a) custo mais baixo e disponibilidade de mão-de-obra;
b) necessidade de possuir recursos que estejam disponíveis a qualquer hora do dia;
c) presença e estabelecimento perto de mercados locais / globais; d) evolução das
ferramentas e nos processos de desenvolvimento de software; e) promoção de
sinergia cultural; f) escalabilidade.

CATEGORIAS DESAFIOS
Confiança
Conflitos
Diferenças culturais
Ensino de DDS
Pessoas
Espírito da equipe
Formação de equipes e grupos
Liderança
Tamanho da equipe
Arquitetura de software
Engenharia de requisitos
Processo
Gerência de configuração
Processo de desenvolvimento
Tecnologia de colaboração
Tecnologia
Telecomunicações
Coordenação, controle e interdependência
Gestão de portfólio de projetos
Gerência do risco
Gestão Legislação (incentivos fiscais e tributários)
Legislação (propriedade intelectual)
Modelos de negócio
Seleção e alocação de projetos
Awareness
Contexto
Dispersão geográfica e temporal
Comunicação
Estilo de comunicação
Formas de comunicação
Fusos horários
Figura 2.2 – Principais desafios no DDS, adaptado de Audy e Prikladnicki (2007).

Segundo Costa (2010), além da redução de custos de desenvolvimento e da

expansão de mercado, as organizações também querem ter equipes cada vez mais
capacitadas, o que nem sempre é possível encontrar num mesmo local. Com
pessoas capacitadas em lugares diferentes, pode não ser viável deslocar todas para
um mesmo ambiente físico, o que estimula o desenvolvimento distribuído. Baroff
 25

(2002) apud Costa (2010) destaca que “um time formado por uma gama de
conhecimentos diferentes é capaz de realizar um variado número de ações”.

O desenvolvimento de software sempre se apresentou de forma complexa.

Entretanto, Audy e Prikladnicki (2007) apontam que o DDS aumentou o número de
desafios deste processo, ao acrescentar fatores como dispersão física, distância
temporal e diferenças culturais. A figura 2.2 apresenta uma compilação dos
principais desafios enfrentados pelo DDS, agrupados por categorias. Alguns dos
desafios podem ser influenciados por mais de uma categoria, mas foram
classificados na categoria de maior influência.

2.3.1. Níveis de Dispersão e Modelos de Negócio

É possível caracterizar de forma mais específica o DDS quando se faz uso de

dois conceitos: os níveis de dispersão e os modelos de negócio. Com base nestes
conceitos, pode-se observar que o desenvolvimento distribuído de software pode
assumir algumas configurações distintas.

Segundo Audy e Prikladnicki (2007), uma característica importante em

projetos de DDS diz respeito à correta definição dos níveis de dispersão dos
stakeholders envolvidos no processo. As dificuldades em um determinado cenário de
dispersão global podem ser bastante diferentes das dificuldades em um cenário de
dispersão local. Por isso, é importante entender o nível de distância e suas
consequências para a equipe. Existem quatro situações que verificam o tipo de
distância física e suas características principais:

 Mesma localização física: situação em que a empresa possui toda a

equipe no mesmo local físico. Dessa forma, não existem dificuldades para
a realização de reuniões e a interação é facilitada tanto pela proximidade
física como pela inexistência de problemas com fuso horário e diferenças
culturais;

 Distância nacional: cenário em que a equipe encontra-se distribuída em

um mesmo país. Aqui, as reuniões físicas são menos frequentes e,
dependendo do país, podem existir dificuldades de fuso horário e as
diferenças culturais podem ser mais acentuadas;
 26

 Distância continental: aqui, a equipe está localizada em mais de um país,

necessariamente dentro de um mesmo continente. As reuniões físicas são
mais difíceis de serem realizadas e o fuso horário exerce um papel mais
importante, podendo dificultar algumas interações;

 Distância global: situação em que a equipe está localizada em países

diferentes e em continentes diferentes. As reuniões ocorrem basicamente
no início dos projetos e aqui as diferenças culturais, comunicação e fusos
horários podem se tornar impedimentos para o trabalho.

Do ponto de vista organizacional, podem ser observadas algumas

configurações que influenciam diretamente o DDS. Com base nos conceitos de
terceirização e estruturas organizacionais, Audy e Prikladnicki (2007) enumeram
quatro modelos de negócio:

 Onshore insourcing: é um dos mais conhecidos modelos de negócio. Aqui,

um departamento ou uma subsidiária da empresa, localizada no mesmo
país (onshore), provê os serviços de software através de projetos internos
(insourcing);

 Onshore outsourcing ou outsourcing: aqui, é contratada uma empresa

terceirizada localizada no mesmo país que a empresa (onshore) para o
desenvolvimento de serviços ou produtos de software;

 Offshore outsourcing ou offshoring: neste modelo, é feita a contratação de

uma empresa terceirizada que, necessariamente, deve estar localizada em
um país diferente da empresa contratante (offshore);

 Offshore insourcing ou captive/internal offshoring: neste caso, a própria

empresa possui uma subsidiária para o provimento dos serviços de
desenvolvimento de software (insourcing), que deve estar localizada em
um país diferente da matriz da empresa ou empresa contratante (offshore).

Nidiffer e Dolan (2005) lembram ainda outras configurações de

desenvolvimento distribuído: através de parcerias entre organizações distintas e
através da aquisição de aplicações, ferramentas, tecnologia de terceiros.
 27

2.4. O PMBOK aplicado ao DDS em organizações públicas

A 4ª. edição do PMBOK institui 42 processos, que podem ser analisados sob
duas dimensões distintas: áreas de conhecimento e grupos de processos. Agora,
considerando a dimensão de áreas de conhecimento, será feita uma abordagem a
respeito da utilização dos processos em DDS em organizações públicas.

2.4.1. Gerenciamento da Integração

O gerenciamento da integração do projeto visa garantir, basicamente, que

todos os elementos do projeto estejam devidamente coordenados. A 4ª. edição do
PMBOK institui 5 processos para o gerenciamento da integração em um projeto.

O processo “Desenvolver Termo de Abertura do projeto” pertence ao grupo de

processos de iniciação e corresponde à elaboração de um documento formal que
autoriza o início de um projeto ou de uma fase. Wirick (2009) afirma que, na iniciativa
pública, este processo pode requerer a interação com os stakeholders para garantir
seu apoio inicial e para buscar a criação do projeto em conjunto com os mesmos.
Segundo o autor, neste caso, raramente o projeto é criado unilateralmente sem a
participação de um conjunto amplo de stakeholders.

O processo “Desenvolver Plano de gerenciamento do projeto”, pertencente ao

grupo de processos de planejamento, tem como objetivo, basicamente, agrupar os
produtos de todos os processos de planejamento em um único documento, de forma
coerente e consistente. Este documento, o plano de gerenciamento do projeto, é
desenvolvido através de processos integrados e está sujeito a atualizações
progressivas ao longo de todo o projeto, devidamente controladas.

O processo “Orientar e gerenciar a execução do projeto”, pertencente ao

grupo de processos de execução, visa executar o que está descrito no plano de
gerenciamento do projeto. Wirick (2009) lembra que uma organização do setor
público também precisa se preocupar em buscar o alinhamento à legislação (aqui se
incluem as questões de propriedade intelectual).

O processo “Monitorar e controlar o trabalho do projeto” pertence ao grupo de

processos de monitoramento e controle e corresponde ao acompanhamento, revisão
e ajuste do progresso para o atendimento dos objetivos de desempenho definidos no
 28

plano de gerenciamento do projeto. Para um monitoramento eficiente em projetos de

DDS, Siqueira e Silva (2006) recomendam, com base na literatura, que a capacidade
em efetuar estimativas do gerente do projeto seja aperfeiçoada e que as métricas de
desempenho utilizadas sejam práticas. Segundo Audy e Prikladnicki (2007), a
utilização de métricas em software é um componente essencial para um
monitoramento efetivo do progresso; em ambientes de DDS, o principal foco das
métricas é a melhoria da coordenação. Wirick (2009) lembra que, nos projetos do
setor público, os desvios do projeto frequentemente são identificados por
stakeholders externos, recomendando que a equipe evite disfarçar um eventual
desempenho negativo.

O processo “Realizar o controle integrado de mudanças”, também

pertencente ao grupo de processos de monitoramento e controle, é conduzido do
início ao fim do projeto e consiste em revisar, aprovar e gerenciar as mudanças no
projeto (documentos, entregas, ativos de processos organizacionais). No
desenvolvimento de software, este processo normalmente é executado quando é
feito o gerenciamento de configuração e mudança do mesmo. Pressman (2010)
define o gerenciamento de configuração e mudança como um conjunto de atividades
para a gerência da mudança por meio da identificação, da definição de
versionamento, controle e auditoria dos produtos de trabalho propensos à mudança.
Segundo Audy e Prikladnicki (2007), o gerenciamento da configuração e mudança
em ambientes distribuídos apresenta novos desafios, tais como a gerência de
modificações simultâneas em diferentes locais, a aplicação de padrões e a
coordenação das modificações de forma efetiva.

Por sua vez, o processo “Encerrar o projeto ou fase” corresponde ao

encerramento de todas as atividades, de todos os grupos de processos de
gerenciamento do projeto, de forma a encerrar formalmente o projeto ou a fase. Para
os projetos de DDS, Siqueira e Silva (2006), com base na literatura, recomendam a
verificação dos resultados e registros quanto à sua completude. Por sua vez, Wirick
(2009) lembra que a maioria das organizações do setor público possui requisitos que
determinam o arquivamento e retenção de documentos por determinados períodos
de tempo; neste caso, o autor recomenda uma consulta a um especialista nos
requisitos do projeto em questão.
 29

2.4.2. Gerenciamento das Comunicações

O gerenciamento das comunicações do projeto inclui os processos que

buscam garantir que todas as informações acerca do projeto serão geradas,
coletadas, distribuídas, armazenadas, recuperadas e organizadas de forma
acessível. A 4ª. edição do PMBOK institui 5 processos para o gerenciamento das
comunicações em um projeto.

O processo “Identificar as partes interessadas” pertence ao grupo de

processos de iniciação e tem como objetivo o mapeamento de todos os stakeholders
do projeto e a documentação de seus interesses, envolvimento e impacto no
sucesso do projeto. Num ambiente de DDS, Audy e Prikladnicki (2007) afirmam que
a capacidade de identificação dos stakeholders é prejudicada, pois não existe a
percepção presencial do ambiente onde o software em desenvolvimento será
utilizado. Wirick (2009) alerta que existem leis e exigências políticas que demandam
a participação de um maior número de stakeholders em projetos do setor público do
que no setor privado. O autor também sugere a identificação de pontos acessíveis
de contato e pessoas que podem ajudar na comunicação com os stakeholders.

O processo “Planejar as comunicações”, pertencente ao grupo de processos

de planejamento, busca determinar as necessidades de informação dos
stakeholders e definir as abordagens de comunicação. A principal saída deste
processo é o Plano de gerenciamento das comunicações. Em projetos de DDS, a
falta de comunicação face a face faz com que novas tecnologias de comunicação
sejam utilizadas, viabilizando a comunicação no projeto (SOUZA et al, 2008). Ainda
assim, Junior et al (2009) indicam a realização de reuniões frequentes através de
mecanismos de teleconferência e videoconferência, além de reuniões presenciais,
sempre que possível. Os autores, inclusive, recomendam que seja feito um
planejamento cuidadoso em relação às ferramentas que serão utilizadas na
comunicação, para evitar possíveis interferências. Além disso, recomendam também
a adoção de um idioma comum a todos, sugerindo que pessoas com culturas
semelhantes trabalhem juntas.

O processo “Distribuir as Informações”, pertencente ao grupo de processos de

execução, tem como objetivo a disponibilização das informações necessárias aos
stakeholders do projeto, conforme planejado. Wirick (2009) afirma que existem dois
 30

fatores que tornam a comunicação em projetos do setor público mais formal: o nível
dos riscos envolvidos na comunicação em si e o nível de “ruído” que pode atrapalhar
as comunicações. Para diminuir o ruído nas comunicações, o autor recomenda a
comunicação redundante, isto é, enviar a informação e assegurar-se de que a
informação foi recebida corretamente. Junior et al (2009), acerca de projetos de
DDS, recomendam a criação de uma base de conhecimento on-line, de forma a
permitir tanto o acesso a informações como o acompanhamento do projeto, por parte
de todas as equipes envolvidas no mesmo. Os autores também sugerem a
institucionalização dos resultados obtidos para todos os envolvidos do projeto.

O processo “Gerenciar as expectativas das partes interessadas”, também

pertencente ao grupo de processos de execução, consiste em comunicar-se e
interagir com os stakeholders de forma a atender as suas necessidades e solucionar
questões à medida que ocorrerem. No setor público, Wirick (2009) afirma que este
processo requer que o gerente do projeto tenha um bom conhecimento da
organização e a habilidade de interagir com os complexos níveis hierárquicos. O
desafio dos gerentes de projetos do setor público, segundo o autor, é competir,
buscando o sucesso, pelo tempo e pela atenção dos stakeholders dos projetos. Para
tanto, é necessário encontrar maneiras criativas de comunicar-se e investir o tempo
necessário para manter os stakeholders informados, satisfazer suas necessidades
por informações e criar uma ampla compreensão do projeto.

O processo “Reportar o desempenho” pertence ao grupo de processos de

monitoramento e controle e consiste em coletar e distribuir informações acerca do
desempenho do projeto. Wirick (2009) sugere a criação de um pequeno relatório
sobre o status do projeto, considerando as informações mais importantes. O autor
também recomenda que, se necessário, sejam criados múltiplos formatos de
relatório, assegurando a coerência entre eles. Junior et al (2009) afirmam que o uso
de métricas em projetos de DDS pode auxiliar neste processo. Os autores também
afirmam que a liberação frequente de versões do software que está sendo
desenvolvido também contribui para que os stakeholders tomem ciência do
andamento do projeto.

Em projetos de DDS, Audy e Prikladnicki (2007) alertam que muitos conflitos

de comunicação podem ser evitados quando o contexto de cada integrante da
equipe é analisado e compartilhado. Além disso, os autores ressaltam a importância
 31

de comunicar a todos o quê, quem, onde e, principalmente, acerca de

documentação e código. Carneiro (2010) lembra também que não é raro descobrir
novos stakeholders durante o desenvolvimento do projeto ou até mesmo após o
término do mesmo. Por isso, as ferramentas e técnicas de comunicação precisam
ser interativas, criativas e sensíveis.

2.4.3. Gerenciamento do Escopo

O gerenciamento do escopo do projeto tem como objetivo garantir que o

projeto inclui todo o trabalho necessário, e somente o necessário, para a sua
conclusão com sucesso. A 4ª. edição do PMBOK institui 5 processos para o
gerenciamento do escopo em um projeto. No desenvolvimento de software, alguns
destes processos normalmente são executados através da chamada engenharia de
requisitos. Segundo Pressman (2010), a engenharia de requisitos consiste em um
conjunto de atividades e técnicas que permitem a compreensão dos requisitos de um
software.

O processo “Coletar os requisitos” pertence ao grupo de processos de

planejamento e corresponde à definição e documentação das funções e
funcionalidades do projeto e do produto que são necessárias para o atendimento
das necessidades e expectativas das partes interessadas. Além da documentação
dos próprios requisitos, uma das saídas deste processo é o Plano de gerenciamento
de requisitos. Siqueira e Silva (2006) fazem algumas recomendações acerca deste
processo em projetos de DDS, tais como: a) padronizar os documentos; b) definir
ferramentas e formatos compatíveis; c) estudar a cultura local dos stakeholders; d)
padronizar os nomes dos artefatos; e) confirmar os requisitos diretamente com os
stakeholders, quando existirem intermediários.

O processo “Definir o escopo”, também pertencente ao grupo de processos

de planejamento, tem como objetivo o desenvolvimento de uma descrição detalhada
do projeto e do produto: a Declaração de escopo. Pressman (2010) explica que o
escopo de um projeto de software não pode ser ambíguo e precisa ser
compreensível tanto do ponto de vista de gerenciamento como do ponto de vista
técnico. No que diz respeito a organizações do setor público, Wirick (2009)
recomenda que sejam estabelecidas premissas na Declaração de escopo, como
forma de proteção da equipe, principalmente em se tratando de dependências
 32

externas ao projeto. O autor também alerta para que sejam consideradas as

aprovações e permissões que venham a ser necessárias para o projeto, no processo
de definição do escopo.

O processo “Criar a estrutura analítica do projeto (EAP)”, também do grupo de

processos de planejamento, consiste em subdividir as entregas e o trabalho em
componentes menores e de mais fácil gerenciamento. Pressman (2010) afirma que a
decomposição do software em funcionalidades torna o projeto mais gerenciável.
Wirick (2009) ilustra como boa prática a apresentação da EAP aos stakeholders
principais, para requisitar a compreensão e aprovação por parte deles.

O processo “Verificar o escopo” pertence ao grupo de processos de

monitoramento e controle e, segundo o PMI (2008), tem como objetivo “a
formalização da aceitação das entregas concluídas do projeto”. Wirick (2009) afirma
que, nas organizações do setor público, obter esta formalização pode ser um
desafio, devido à ampla quantidade de stakeholders e ao tempo que será utilizado
para se analisar os resultados.

O processo “Controlar o escopo”, também pertencente ao grupo de processos

de monitoramento e controle, consiste no monitoramento do escopo do projeto e do
produto e no gerenciamento das mudanças feitas na linha de base do escopo. Este
processo é executado através do gerenciamento de configuração e mudança, no
desenvolvimento de software. Wirick (2009) sugere que o gerente do projeto
assegure que os stakeholders conhecem o processo de gerenciamento de
mudanças no escopo. Do ponto de vista de projetos de DDS, Siqueira e Silva (2006)
recomendam que exista uma pessoa responsável por coordenar os requisitos em
cada local.

Wirick (2009) recomenda que não se prossiga com os processos de

gerenciamento de requisitos enquanto o Termo de abertura não estiver definido.
Além disso, o autor afirma que projetos têm maior chance de sucesso através da
fragmentação do escopo em projetos menores e mais claramente definidos.

2.4.4. Gerenciamento de Riscos

O gerenciamento de riscos do projeto tem como objetivo o aumento da

probabilidade e do impacto dos eventos positivos e a redução da probabilidade e do
 33

impacto dos eventos negativos. A 4ª. edição do PMBOK institui 6 processos para o
gerenciamento dos riscos em um projeto.

O processo “Planejar o gerenciamento dos riscos” pertence ao grupo de

processos de planejamento e tem como objetivo a definição da forma de condução
do gerenciamento dos riscos em um projeto. A saída deste processo é o próprio
plano de gerenciamento de riscos. Audy e Prikladnicki (2007), com base em Karolak
(1998), afirmam que projetos de DDS possuem 3 categorias gerais de risco: a)
organizacional; b) técnico e c) comunicação. Wirick (2009) menciona também as
seguintes categorias, no que diz respeito a projetos do setor público: a) publicidade;
b) política e c) redução de recursos. O autor também recomenda atenção quanto ao
mapeamento das tolerâncias dos stakeholders no setor público. Estes stakeholders
têm pouca tolerância a riscos que possam contribuir com uma visibilidade negativa
do projeto.

O processo “Identificar os riscos”, também pertencente ao grupo de processos

de planejamento, consiste em determinar e documentar as características dos riscos
que podem vir a afetar o projeto em algum nível. Segundo Audy e Prikladnicki
(2007), o gerenciamento de riscos precisa ocorrer em nível de projeto e em nível
organizacional, ”no sentido de analisar as vantagens de um determinado projeto ser
desenvolvido de forma distribuída e, caso seja, quais os riscos envolvidos”. Os
autores afirmam que os riscos eventualmente identificados na análise organizacional
precisam ser repassados para o gerente do projeto. Além disso, os autores também
recomendam a utilização de listas de riscos comuns em ambientes de DDS, de
forma a não ignorar potenciais riscos.

O processo “Realizar a análise qualitativa dos riscos”, também pertencente ao

grupo de processos de planejamento, tem como objetivo a priorização dos riscos
identificados para análise ou ações adicionais. Segundo Leme (2007), as regras de
avaliação geralmente são especificadas pela organização antes do projeto e
incluídas como ativos organizacionais. Karolak (1998) apud Audy e Prikladnicki
(2007), afirma que riscos que estiverem presentes em mais de uma categoria devem
estar no topo da lista de prioridades em um projeto de DDS.

O processo “Realizar a análise quantitativa dos riscos” também pertence ao

grupo de processos de planejamento e consiste em analisar numericamente os
efeitos dos riscos identificados no projeto. Leme (2007) afirma que este cálculo é
 34

muito importante para que se determinem os riscos que serão tratados e o seu
respectivo grau de importância. Enquanto no setor privado é possível converter o
impacto dos riscos em valores financeiros, no setor público, isto normalmente não é
possível. Assim, Wirick (2009) recomenda a utilização de uma escala com critérios
de avaliação relevantes para a organização e os stakeholders do projeto. Leme
(2007), por sua vez, afirma que a responsabilidade pela definição da técnica de
avaliação de riscos deve ser da organização.

O processo “Planejar as respostas aos riscos” também pertence ao grupo de

processos de planejamento e tem como objetivo a elaboração de ações que
aumentem as oportunidades e reduzam as ameaças ao projeto. Wirick (2009)
discorre acerca de estratégias de resposta a algumas categorias de riscos inerentes
ao setor público, tais como riscos legais e riscos ocasionados por restrições
administrativas, como processos pré-determinados. Nestes casos, o autor afirma
que uma solução fácil seria alterar o projeto (redução de escopo, por exemplo) de
forma a evitar que o mesmo seja impactado, pois leis não podem ser alteradas e a
alteração de processos pode requerer a intervenção de muitos stakeholders,
acarretando o surgimento de mais riscos.

O processo “Monitorar e controlar os riscos” pertence ao grupo de processos

de monitoramento e controle e consiste em implementar os planos de respostas e
acompanhar os riscos, monitorar riscos residuais, identificar novos riscos e avaliar a
eficácia do processo de riscos. Leme (2007) afirma que, neste processo, deve ser
retomada toda a documentação elaborada em relação a riscos, para compará-la com
a realidade do projeto, atualizá-la e integrá-la à base de conhecimento institucional.

Audy e Prikladnicki (2007) ainda comentam que, quando a organização não

em experiência com projetos de DDS, a falta de compartilhamento do conhecimento
dos riscos pode gerar diversos problemas inesperados para os projetos envolvidos.
Leme (2007) recomenda que esta disseminação seja feita depois que os riscos já
tiverem sido identificados e mensurados.

2.4.5. Gerenciamento da Qualidade

O gerenciamento da qualidade do projeto visa garantir que o projeto cumpra

os objetivos para os quais foi empreendido, utilizando as políticas de qualidade e
 35

responsabilidade e através das atividades e processos da organização. A 4ª. edição

do PMBOK institui 3 processos para o gerenciamento da qualidade em um projeto.

O processo “Planejar a qualidade”, pertencente ao grupo de processos de

planejamento, consiste em identificar os requisitos e padrões de qualidade do
projeto e do produto, documentando as formas de verificação de conformidade. A
principal saída deste processo é o Plano de gerenciamento da qualidade do projeto.
Wirick (2009) afirma que é comum que os stakeholders nos projetos do setor público
não determinem os requisitos de qualidade do produto, por falta de conhecimento
legal ou até mesmo para evitar abordagens por parte de outros stakeholders. Por
isso, o autor afirma que o levantamento de requisitos é um fator crítico em projetos
do setor público. Acerca de recomendações em projetos de DDS, Siqueira e Silva
(2006) afirmam que devem ser estabelecidos padrões mínimos de qualidade entre
as equipes distribuídas. Audy e Prikladnicki (2007) destacam que um processo de
desenvolvimento comum às equipes é fundamental em projetos de DDS, sendo a
sincronização das atividades um dos principais objetivos a serem alcançados por
meio disto.

O processo “Realizar a garantia da qualidade” pertence ao grupo de

processos de execução e tem como objetivo assegurar que estão sendo utilizados
os padrões e definições apropriados, através de auditorias dos requisitos de
qualidade e dos resultados das medições de controle da qualidade. Siqueira e Silva
(2006) recomendam que, em projetos de DDS, sejam consideradas as diferenças de
percepção de não conformidades devido às distintas culturas regional e
organizacional. Quanto a projetos do setor público, Wirick (2009) lembra que as
auditorias podem vir a ser uma fonte de estresse, devido à possibilidade de
aplicação de sanções pelo não cumprimento de padrões específicos. Além disso, o
autor menciona que é difícil manter o foco nas mesmas ao longo do projeto.

O processo “Realizar o controle da qualidade”, pertencente ao grupo de

processos de monitoramento e controle, tem como objetivo monitorar e registrar os
resultados das execuções das atividades de qualidade, buscando a avaliação do
desempenho e recomendação de mudanças. Wirick (2009) afirma que o ideal é criar
um equilíbrio produtivo entre os objetivos do projeto e as verdadeiras necessidades
dos responsáveis pelos padrões de qualidade.
 36

2.4.6. Gerenciamento do Tempo

O gerenciamento do tempo do projeto contém os processos necessários para

garantir que o projeto seja concluído no prazo estimado. A 4ª. edição do PMBOK
institui 6 processos para o gerenciamento do tempo em um projeto.

O processo “Definir as atividades” pertence ao grupo de processos de

planejamento e consiste na identificação das ações que devem ser realizadas para
produzir as entregas do projeto. Wirick (2009) afirma que um bom gerenciamento de
projeto obriga a identificação das entregas do projeto antes de seguir com este
processo, pois o ideal é que sejam identificadas as atividades necessárias para as
entregas previstas na EAP. O autor também lembra que os projetos do setor público
devem identificar atividades relacionadas a compras e obtenção de recursos
humanos, assim como atividades de pesquisa de leis e impedimentos
administrativos que possam influenciar o projeto.

O processo “Sequenciar as atividades”, também pertencente ao grupo de

processos de planejamento, tem com objetivo determinar e documentar os
relacionamentos entre as atividades do projeto. Por sua vez, o processo “Estimar os
recursos da atividade” também pertence ao grupo de processos de planejamento e
consiste em estimar os tipos e quantidades de recursos (material, pessoas,
equipamentos, suprimentos) necessários para cada atividade. Já o processo
“Estimar as durações da atividade”, também pertencente ao grupo de processos de
planejamento, consiste em estimar os períodos de trabalho necessários para a
conclusão das atividades com os recursos estimados. Leal et al (2010) recomendam
a distribuição de atividades que possibilitem o mínimo de interação entre equipes
distribuídas num ambiente de DDS, de forma a reduzir os impactos negativos dos
problemas de comunicação e colaboração. Siqueira e Silva (2006), acerca de
projetos DDS, recomendam que sejam consideradas as necessidades de viagens
durante a execução das atividades. Além disso, também sugerem considerar a
dificuldade na negociação de requisitos devido à distribuição das pessoas. Wirick
(2009) lembra também que, no setor público, devem ser levados em consideração
os processos que envolvem outros departamentos (por exemplo, contratações,
compras, análises legais).
 37

O processo “Desenvolver o cronograma” pertence ao grupo de processos de

execução e tem como objetivo a criação do cronograma do projeto através da
análise das atividades e seus relacionamentos, recursos estimados e restrições.
Quanto a projetos de DDS, Siqueira e Silva (2006) apontam as diferenças de
horários de trabalho, de calendário (feriados, por exemplo), a dificuldade no
agendamento de reuniões, o tempo de importação e exportação, o tempo de
transmissão de informações, entre outros, como fatores críticos a serem
considerados no planejamento. Wirick (2009) diz que é importante que o gestor do
projeto reconheça que o cronograma está sendo desenvolvido com o máximo de
informações disponíveis no momento e que o mesmo sempre vai mudar.

O processo “Controlar o cronograma”, pertencente ao grupo de processos de

monitoramento e controle, consiste em monitorar o andamento do projeto de forma a
atualizar seu andamento, e em gerenciar as mudanças na linha de base do
cronograma. Em projetos do setor público, Wirick (2009) afirma que, embora
mudanças desnecessárias no cronograma do projeto precisem ser evitadas,
abertura para as mudanças é essencial. Neste caso, os objetivos do projeto e as
preferências dos stakeholders devem ser levados em consideração. O autor também
afirma que os atrasos em projetos ocorrem com frequência no setor público e que a
antecipação do término de atividades não vai necessariamente voltar a equilibrar o
cronograma.

2.4.7. Gerenciamento dos Custos

O gerenciamento dos custos do projeto contém os processos envolvidos para

estimativas, orçamentação e controle dos custos. A 4ª. edição do PMBOK institui 3
processos para o gerenciamento dos custos de um projeto.

O processo “Estimar os custos” pertence ao grupo de processos de

planejamento e consiste em desenvolver uma estimativa dos custos dos recursos
monetários necessários para a conclusão das atividades do projeto. Por sua vez, o
processo “Determinar o orçamento”, também pertencente ao grupo de processos de
planejamento, tem como objetivo agregar os custos estimados das atividades ou
entregas para estabelecer uma linha de base de custos. Já o processo “Controlar os
custos” pertence ao grupo de processos de monitoramento e controle e consiste em
 38

monitorar o andamento do projeto para atualização de seu orçamento e em

gerenciar as mudanças feitas na linha de base de custos.

Segundo Pagno (2010), existem três fatores que influenciam os custos

específicos de projetos de DDS: forma de separação dos grupos (agrupamento,
distância física e separação temporal), regiões envolvidas (culturas regionais,
idiomas e diferenças dos locais) e organizações participantes (culturas
organizacionais, infra-estrutura e relação legal). Dentre os possíveis custos
específicos em projetos de DDS, o autor cita: viagens programadas e não
programadas, cursos de proficiência, rede de telecomunicações e diferenças
cambiais.

Wirick (2009) explica que, normalmente, os gestores de projetos no setor

público não conseguem determinar o custo de seus projetos. Isto resulta em
decisões ruins de investimento e não permite uma boa avaliação da performance do
gestor do projeto ou da equipe. O autor comenta ainda que é ainda mais difícil
quantificar os resultados no setor público do que no setor privado. Mesmo que as
informações de custo estejam disponíveis, não é simples determinar quais destas
informações serão utilizadas para a medição. Além disso, pode haver alguma
resistência em descobrir o custo de um projeto.

2.4.8. Gerenciamento das Aquisições

O gerenciamento das aquisições do projeto corresponde aos processos

necessários para a compra ou aquisição de produtos, serviços ou resultados para o
projeto. A 4ª. edição do PMBOK institui 4 processos para o gerenciamento das
aquisições de um projeto.

O processo “Planejar as aquisições” pertence ao grupo de processos de

planejamento e consiste na documentação das decisões de compras do projeto, sua
abordagem e potenciais fornecedores. Já o processo “Realizar as aquisições”,
pertencente ao grupo de processos de execução, tem como objetivo obter respostas
dos fornecedores, selecionar um deles e contratá-lo. Por sua vez, o processo
“Administrar as aquisições” pertence ao grupo de processos de monitoramento e
controle e tem como objetivo gerenciar as relações de aquisição, monitorando o
desempenho do contrato, realizando mudanças e correções quando necessário. Por
 39

fim, o processo “Encerrar as aquisições”, pertencente ao grupo de processos de

encerramento, consiste em finalizar todas as aquisições do projeto.

Basicamente, os processos de aquisição em organizações do setor público

brasileiro devem seguir as regras estabelecidas pela Lei Federal n°. 8666, de 21 de
junho de 2003 (Lei de Licitações e Contratos). (XAVIER et al, 2010). Segundo Wirick
(2009), a responsabilidade pela contratação de bens e serviços em organizações do
setor público normalmente é bem definida e atribuída a escritórios ou departamentos
de compras, o que pode afetar o cronograma, o orçamento e a qualidade do projeto,
além de representar um risco ao mesmo. O autor recomenda que a equipe do
projeto trabalhe em sintonia com os processos de aquisição da organização,
tornando o departamento de compras um aliado em potencial, de forma a conseguir
bens e serviços que venham a contribuir para o projeto.

No que diz respeito a projetos de DDS, Leal et al (2010) considera válida a

opção de terceirização dos testes de integração, sistemas e aceitação do software
que está sendo desenvolvido. Um dos possíveis fatores que pode contribuir para a
adoção desta estratégia é justamente a falta de um ambiente apropriado para testes
na organização. Segundo os autores, a terceirização dos testes para organizações
especialistas pode trazer benefícios como a melhoria da confiabilidade do software,
maior quantidade de testes realizados e maior eficiência.

2.4.9. Gerenciamento dos Recursos Humanos

O gerenciamento dos recursos humanos do projeto corresponde aos

processos envolvidos no planejamento, contratação, mobilização, desenvolvimento e
gerenciamento da equipe do projeto. A 4ª. edição do PMBOK institui 4 processos
para o gerenciamento dos recursos humanos de um projeto.

O processo “Desenvolver o plano de recursos humanos” pertence ao grupo

de processos de planejamento e consiste em identificar e documentar as funções,
responsabilidades, habilidades requeridas e relações hierárquicas do projeto. A
principal saída deste processo é o plano de gerenciamento de recursos humanos.
Por sua vez, o processo “Mobilizar a equipe do projeto”, pertencente ao grupo de
processos de execução, tem como objetivo a confirmação da disponibilidade e a
obtenção da equipe necessária para desempenhar as atividades do projeto. Já o
 40

processo “Desenvolver a equipe do projeto” também pertence ao grupo de

processos de execução e tem como objetivos a promoção da interação e a melhoria
das habilidades e do ambiente global de forma a aprimorar o desempenho do
projeto. Por fim, o processo “Gerenciar a equipe do projeto”, também pertencente ao
grupo de processos de execução, consiste no acompanhamento do desempenho
dos membros da equipe, fornecimento de feedback, resolução de questões e
gerenciamento de mudanças.

Audy e Prikladnicki (2007) afirmam que os encontros de kick-off e marcos do

projeto são as melhores formas de construção de confiança em equipes de DDS.
Embora não seja sempre possível realizar reuniões presenciais com todos os
integrantes (o que os autores recomendam nas etapas iniciais do desenvolvimento),
a interação pode ser feita através de recursos tecnológicos avançados de
comunicação. Ainda sobre ambientes de DDS, Leal et al (2010) sugere que a
identificação das pessoas envolvidas nas equipes pode estimular a confiança e o
compromisso entre os mesmos. Além disso, Siqueira e Silva (2006) recomendam
que seja feita a divulgação da experiência dos membros das equipes.

Wirick (2009) discorre sobre os principais desafios para o gerenciamento de

recursos humanos no setor público. Um deles é a inabilidade de se relacionar a
promoção ao desempenho no projeto. A cultura organizacional do setor público de
não se trabalhar acima da média e evitar riscos também pode ser um ponto de
dificuldade. Outro desafio é o fato de o gestor do projeto, normalmente, não
conseguir selecionar os membros da equipe do projeto com base na experiência. O
autor tece algumas recomendações no gerenciamento de recursos humanos em
projetos deste tipo, como a formação de uma equipe diversificada, o engajamento da
equipe no planejamento do projeto e no processo de tomada de decisões e, se
possível, a promoção da liberdade da equipe para experimentar, aprender e crescer.
 41

3. CONTEXTO DA ANÁLISE

3.1 A Empresa

A empresa XYZ é uma empresa pública de TIC que tem por objetivo a
prestação de serviços de desenvolvimento, processamento e tratamento de
informações, bem como a prestação de outros serviços correlatos. Foi criada em 4
de Novembro de 1974. Seu foco de negócio era atuar na área da previdência e
assistência social. Hoje, após passar por uma fase de reestruturação, diversificou
sua área de atuação, prestando serviços de TI a clientes pertencentes a outras
áreas do setor público, mas ainda mantém como foco principal a área da previdência
e assistência social. Está sediada na cidade de Brasília, Distrito Federal e atua em
todo território nacional e dependências, onde for julgado necessário para o bom
desempenho de suas finalidades.

A empresa não mantém a totalidade dos seus funcionários trabalhando em

áreas relacionadas a projetos. Uma parte do corpo funcional está alocada em outras
áreas, como prestação de serviços de suporte a hardware e fornecimento de infra-
estrutura, sustentação e suporte aos produtos desenvolvidos pela empresa, além do
pessoal alocado na área administrativa. Como o foco deste estudo de caso está
direcionado a uma área especifica da empresa, nos ateremos a apresentar de forma
macro a estrutura organizacional desta área.

Figura 3.1 – Organograma da Diretoria de Desenvolvimento de Produtos e Soluções

Conforme demonstrado na figura 3.1, o corpo funcional da Diretoria de

Desenvolvimento de Produtos e Soluções está distribuído geograficamente; o
desenvolvimento de projetos está distribuído entre 5 (cinco) Estados, que foram
escolhidos para sediar o desenvolvimento de software após a empresa avaliar
 42

alguns aspectos relacionados à captação e retenção de mão-de-obra, dentre os

quais podemos citar: o salário oferecido pela empresa ser considerado compatível
com o custo de vida local e existência de universidades nas regiões, capazes de
abastecer o mercado com profissionais qualificados. Apesar de a empresa possuir
uma estrutura organizacional matricial fraca, essa diretoria estabeleceu que algumas
áreas suas seriam organizadas de forma projetizada e que seu modelo de negócio
seria baseado em gestão de projetos.

3.2 O Programa

Segundo o PMI (2008), os projetos, em programas ou portfólios, são um meio

de atingir metas e objetivos organizacionais, geralmente no contexto de um
planejamento estratégico. Embora um grupo de projetos em um programa possa ter
benefícios distintos, eles também podem contribuir para os benefícios do programa,
para os objetivos do portfólio e para o plano estratégico da organização.

O programa ALFA é um software que tem por objetivo automatizar rotinas e

definir processos para, de uma forma geral, requerer, calcular, conceder, manter,
revisar e consultar benefícios previdenciários.

Historicamente, a idealização desse programa foi originada como uma

solução apontada por uma consultoria contratada pela Coordenação Geral de
Informática do Ministério do Governo Federal, ao qual a empresa XYZ está
subordinada, com o objetivo de diminuir custos, favorecer o processo de fiscalização
e controle, bem como de execução dos débitos e recebimentos indevidos,
aperfeiçoar o atendimento através da modernização do parque tecnológico,
aumentando a segurança e agilizando os processos.

O programa ALFA atualmente é composto por 18 projetos. Abaixo

relacionamos os principais fatores que levaram à sua distribuição geográfica:

 Existência de um requisito de tempo exíguo para a entrega do produto

final.

 A grande complexidade do negócio.

 A considerável extensão do escopo.

 43

 Necessidade da produção de um entregável, com funcionalidades que

extrapolam o escopo de um único projeto, que fosse capaz de atender aos
requisitos básicos para que o negócio estivesse apto a ser utilizado em
sua plenitude.

 O fato da empresa não possuir nenhuma unidade que fosse capaz de

absorver o programa na sua totalidade, sendo, portanto dividido entre as
unidades de desenvolvimento situadas no CE, RJ e SC, conforme ilustrado
na figura 3.2.

Figura 3.2 – Distribuição física do cliente e unidades de desenvolvimento do programa

Outra característica peculiar ao programa é o distanciamento físico entre os

clientes e os projetos; os clientes estão sediados em Brasília, embora não residam
nesta localidade. Normalmente, são convocados para comparecerem à sede do
programa e permanecem nesta localidade por um período de tempo, no qual ficam
dedicados exclusivamente ao projeto. Enquanto convocados, os clientes exercem
funções de fornecimento e validação de requisitos juntamente com os projetos
pertencentes ao programa. Uma vez construídas as entregas, os clientes terão
 44

também a função de testá-las, encaminhar as devidas solicitações de correções e

mudanças e uma vez ajustadas conforme solicitação, fornecer o aceite final do
produto. Ao retornarem à sua base, os clientes assumem seu posto de trabalho
rotineiro, ficando impossibilitados de atuar no programa; assim, para que o trabalho
no programa seja retomado, far-se-á necessária uma nova convocação.

Apesar da empresa XYZ já possuir um processo de desenvolvimento de

software, o mesmo sofreu várias adaptações específicas para o programa ALFA. Na
verdade, foram criados mecanismos auxiliares para gerenciar os requisitos do
programa de forma unificada e para controlar a qualidade, além do estabelecimento
de rotinas e padrões próprios para comportar o desenvolvimento do produto.
 45

4. ANÁLISE CRÍTICA DO PROGRAMA

No processo de desenvolvimento do programa ALFA foram levantados vários

problemas de diferentes naturezas, porém, para atender aos propósitos do presente
trabalho, destacaremos principalmente aqueles relacionados à distribuição
geográfica e ao fato de tratar-se de um programa desenvolvido em uma empresa
pública.

Inicialmente, pretendia-se abranger todas as áreas de conhecimento na

análise. Contudo, devido à política da empresa de não delegar aos projetos
autonomia no gerenciamento de custos essa área de conhecimento foi excluída da
análise. Outra área que não foi abordada é a de Gerenciamento de Aquisições, que
também não é incumbida aos projetos; os projetos transformam as necessidades de
aquisições em riscos e assim é feito um acompanhamento, mesmo que a distância.

Abaixo segue o desenvolvimento da análise de problemas, que foram

divididos conforme as áreas de conhecimento às quais se relacionam, conforme
segue abaixo:

4.1 Qualidade

A empresa XYZ possui uma metodologia própria de desenvolvimento de

sistemas. A metodologia vem sendo difundida entre todas as áreas da empresa que
estão relacionadas ao desenvolvimento de software e se encontra publicada na
Intranet da empresa, de forma a tornar o conhecimento compartilhado e acessível.
Todavia, a metodologia não está robusta e portável o suficiente, para que seja
utilizada por diferentes projetos e programas sem que haja ajuste, mas isso não
configura nenhum impeditivo para o uso da mesma. Uma das características da
metodologia é uma excessiva carga de documentação que precisa ser mantida pelos
projetos, além de possuir um processo bastante burocrático.

Atualmente, a área de qualidade possui poucos recursos na equipe. Esse

fator dificulta a realização de algumas das atividades desempenhadas pela área, de
forma que a qualidade é obrigada a eleger os projetos que serão acompanhados e
monitorados; normalmente os projetos excluídos são os considerados mais
 46

aderentes ao processo, o que significa que pelo menos no início eles foram
acompanhados e monitorados.

Comparando a definição de planejamento da qualidade dada pelo PMBOK “...

o processo de identificação dos requisitos e/ou padrões de qualidade do projeto e do
produto, além da documentação de como o projeto atingirá a conformidade” e a
definição utilizada pela área de qualidade da empresa, foi identificado que na teoria
os processos estão alinhados, mas na prática a área de qualidade ainda não está
realizando todas as atividades de planejamento. O foco do trabalho da qualidade
hoje é a garantia do processo; a garantia do produto ainda está numa fase inicial,
com a reestruturação da área de testes da qualidade, aquisição de novas
ferramentas para impulsionar, modernizar e conseguir resultados mais efetivos, além
da requalificação de seus profissionais, tornando-os capazes de apoiar as equipes
de projetos e desempenhar de forma mais eficaz seu papel dentro da área de
qualidade. Apesar desses esforços para desenvolver a área de qualidade, os
projetos do programa ainda trabalham de forma desalinhada quando avaliados pela
ótica do processo e do produto. Explicando um pouco melhor, as áreas de qualidade
de cada um dos estados envolvidos no desenvolvimento do programa trabalham de
forma diferente e não existe um padrão dentro da própria qualidade. As avaliações
não seguem o mesmo rigor quanto à pontualidade de suas realizações, nem
tampouco quanto à forma como deve ser realizada e o nível de exigência.

Avaliando o programa pela ótica da qualidade, podem ser observados alguns

aspectos que afetaram a qualidade do produto e processo ao longo da execução do
programa. O processo de desenvolvimento de software da empresa não se
apresentou adequado ao programa, então foram adotados alguns ajustes de forma a
tornar o processo usual pelos projetos. Os ajustes foram realizados na fase inicial
dos projetos, mas ao longo da execução do programa, diversas falhas foram
surgindo e as modificações iniciais mostraram-se insuficientes e superficiais. A
implementação constante de mudanças para adequar os projetos ao processo e a
padrões foi refletida nos projetos, exigindo um maior esforço de trabalho por parte
das equipes para conseguir absorver novas atividades dentro do cronograma de
cada projeto ou mesmo configurando atraso no cronograma em função dessas
atividades que não haviam sido planejadas. Após essa breve contextualização,
 47

segue uma lista de pontos afetados direta ou indiretamente com as deficiências

apresentadas nessa área de conhecimento:

 Nem todas as equipes de projeto seguem o processo de desenvolvimento

institucionalizado pela empresa; a avaliação do processo pode não
garantir que o processo será seguido, mas ajuda a coibir o
descompromisso com a utilização do mesmo.

 A cobrança para seguir o processo de desenvolvimento de software da

empresa varia de uma equipe de qualidade para a outra, isso faz com que
os projetos do programa atinjam níveis de qualidade diferentes.

 A metodologia possui modelos específicos para cada um dos diferentes

tipos de artefatos que podem ser criados ao longo do projeto.
Complementarmente, existem também documentos que orientam como os
modelos devem ser preenchidos, identificando o tipo de informação que
cada seção deve conter. Entretanto, não existe nenhuma orientação
específica de como deve ser desenvolvido o conteúdo, o que faz com que
nem todas as equipes desenvolvam os artefatos dentro de uma mesma
padronização.

 A não padronização de soluções comuns no início do programa (padrões

visuais utilizados, base de dados integrada, arquitetura de sistema,
ferramentas utilizadas, tecnologias adotadas) causa atraso e retrabalho
continuamente, uma vez que os padrões vêm sem definidos de forma
gradativa e tardiamente.

 A empresa está passando por um momento de redefinição do seu

processo de desenvolvimento. Durante certo tempo o foco da qualidade
era apenas na garantia do processo, não sendo realizadas auditorias de
qualidade do produto. Atualmente, o foco da empresa está mudando; a
área de testes, que também faz parte da área de qualidade da empresa,
vem ganhando importância e se fazendo mais atuante nos projetos. Ainda
assim, percebe-se uma conscientização arraigada da direção da empresa
quanto à importância da fase de testes, fazendo com que em algumas
circunstâncias os mesmos sejam em grande parte suprimidos, acarretando
em desgastes com o cliente e provocando atrasos.
 48

 Inexistência de uma orientação acerca do conteúdo que deve ser

produzido na elaboração dos artefatos. Isso faz com que a área de
qualidade oriente de diferentes formas um mesmo procedimento,
provocando retrabalho na tentativa de alinhamento e despadronização
quando o mesmo não é feito.

 Nem sempre os planos de projeto são atualizados ao longo da execução

do mesmo, não acompanhando assim, a evolução das mudanças
ocorridas durante este período.

 Inexistência de mecanismos de avaliação da qualidade do produto a ser

construído, bem como de indicadores de qualidade que norteiem o
processo de construção dentro dos patamares esperados. Isso resulta na
realização de fases de homologação muitas vezes desgastantes e
onerosas.

 A devida documentação das alterações realizadas nos artefatos não é

uma prática adotada por todos os projetos, aumentando o nível de
dificuldade em situações onde uma equipe necessita entender o
funcionamento e às vezes utilizar um artefato produzido por uma outra
equipe.

4.2 Recursos Humanos

A empresa XYZ não possui um plano formal de gerenciamento de recursos

humanos, mas ela possui diretrizes bem definidas relacionadas aos aspectos de
contratação e bonificação de pessoas:

 Por se tratar de uma empresa estatal, a contratação de pessoas só poderá

ocorrer através de concurso de seleção pública. As novas contratações
visam suprir vagas para cargos específicos, independente da qualificação
da pessoa contratada. Cabe à empresa disponibilizar treinamento para
adequar as pessoas a desempenharem as funções para as quais foram
designadas. Atualmente, nas unidades de desenvolvimento os novos
contratados são submetidos a uma bateria de palestras acerca do negócio
da empresa e em seguida a um conjunto de treinamentos relacionados ao
processo de desenvolvimento e as ferramentas utilizadas. A empresa
 49

definiu uma política de realização de concursos a cada dois anos, a fim de

suprir as vagas existentes e manter uma fila de cadastro de reserva para
diminuir o impacto da saída repentina de recursos, principalmente da área
de TIC. A aquisição de novos recursos para os projetos se dá através de
solicitação ao gerente da unidade de desenvolvimento; o gestor do projeto
define apenas o perfil desejado e o gerente da unidade de
desenvolvimento tenta captar o recurso dentre os novos contratados,
identificando o perfil através de entrevista, ou realizando uma negociação
dentre os demais projetos para obtenção do perfil desejado.

 Até pouco tempo atrás, a única bonificação existente era a gratificação

concedida aos gestores de projeto. Recentemente a empresa implantou
um sistema de bonificação variável e setorial, baseado em indicadores
trimestrais, mas que não configura uma gratificação para quem trabalha
em projetos.

A alocação financeira para o gerenciamento de RH é realizada apenas no

âmbito da empresa, pois os projetos não têm nenhuma autonomia financeira.

Atualmente, existe um limite para o número de projetos que podem ser

desenvolvidos simultaneamente. Mesmo com essa limitação, os projetos ao
atingirem seu estágio final, onde sua demanda fica reduzida, só podem liberar
alguns recursos quando os mesmos forem necessários em outros projetos. Nesta
mesma situação podemos citar a dificuldade na remoção/transferência de
funcionários com perfis ou comportamentos não compatíveis com a equipe, o que
gera uma superalocação involuntária dos projetos, comprometendo os seus
indicadores relativos à produtividade. Por outro lado, os projetos que estão
necessitando de novos recursos, nem sempre são atendidos com a urgência
necessária. A solicitação dos novos recursos deve ser encaminhada ao gerente da
unidade de desenvolvimento, que realizará um levantamento nos demais projetos
dos recursos que poderão ser liberados e que possuem as características que estão
sendo buscadas.

A empresa atua em âmbito nacional, possuindo uma tabela salarial única para
cada cargo existente na empresa. Portanto, os funcionários alocados em diferentes
regiões do país, acabam recebendo os mesmos proventos, independente do custo
 50

de vida local. Tal fato inviabiliza a retenção de funcionários em determinadas

localidades.

Observou-se também a ausência de um treinamento efetivo por parte da

empresa para a formação dos gestores. Verificou-se a necessidade de investimento
por parte da empresa, principalmente, no desenvolvimento das habilidades
interpessoais do gestor, tais como comunicação, administração de conflitos,
liderança, motivação e negociação. Muitos dos atuais gestores não passaram por
um treinamento adequado que os capacitasse a desempenhar as atividades
requeridas. Os gestores são escolhidos simplesmente por serem bons técnicos e
não por apresentarem conhecimento e experiência em gestão de projetos. Primeiro
se tornam gestores para só depois passarem a aprender como trabalhar na gestão.
Esse fato acaba tendo impacto no bom desempenho do projeto.

Visto que nas organizações públicas, o ingresso de funcionários ocorre

através de concursos públicos, que fixam os funcionários de carreira, isso acarreta
problemas relativos à produtividade de alguns funcionários, dificilmente tratado
devido à presunção de estabilidade. Outro aspecto relativo à forma de contratação é
a dificuldade, em algumas situações, na alocação de funcionários com o perfil
adequado para a realização de uma determinada atividade, não sendo possível, na
maior parte das vezes, a formação de pessoas no perfil desejado a curto prazo.
Diferentemente do setor privado, onde é possível a seleção de um candidato, pelo
mesmo possuir habilidades diferenciadas e desejadas pela empresa contratante.

Foram identificadas situações onde houve morosidade e

descomprometimento no atendimento a requisição entre projetos, no tocante ao
fornecimento de informações ou a resolução de algum problema. Tais fatos são
gerados principalmente pela falta de confiança e de senso de equipe entre as
pessoas envolvidas e fisicamente distantes.

Inexistência de gerenciamento de conflitos no âmbito do programa. Podemos

citar como exemplo as reuniões de videoconferência, que quando tratavam de temas
relacionados ao cumprimento dos prazos do cronograma, pressionando os projetos,
surgiam conflitos entre as equipes. O não tratamento de tais situações acaba por
dificultar o clima no ambiente organizacional, influenciando negativamente em
futuras interações entre os projetos.
 51

4.3 Risco

Segundo TAVOLARO (2001), quando o futuro passa a ser um cenário traçado

por decisões e quando os indivíduos têm a consciência da complexidade que faz do
futuro algo a ser concretizado entre o provável e o improvável, as incertezas deixam
de ser perigos que exteriormente afligem os indivíduos para se tornarem riscos
decorrentes de decisões passadas e presentes.

Os riscos em projetos podem ter suas causas relacionadas a diversos fatores.

No contexto da empresa em análise, podemos mencionar dois deles como
principais. São eles:

 O fato da empresa de TI aqui retratada ser uma empresa pública, com

características bem traçadas com relação a aspectos como contratação de
serviços, aquisição de produtos, admissão de funcionários, gestão
orçamentária, processo de tomada de decisão, estruturação das atividades
administrativas, estratégia de definição do corpo executivo.

 O cliente deste programa também fazer parte do setor público, delineando

assim questões bem inerentes a esta área, relacionadas à cultura
organizacional enquanto cliente, liberação de orçamento para atividades
relacionadas ao programa, disponibilidade de stakeholders chave.

Atualmente, o gerenciamento de riscos na empresa XYZ se resume

simplesmente à identificação dos mesmos. Isso é feito na fase inicial do projeto e a
sua atualização é realizada mensalmente, pois é necessária para compor o
documento de acompanhamento do projeto, acompanhando a evolução do mesmo e
consequentemente, a possível alteração dos riscos levantados inicialmente.

Em geral, não existe um plano de prevenção ou contingenciamento de riscos.

Portanto, os riscos estão sendo tratados à medida que os mesmos se concretizam.
Identificamos também que o tratamento desses riscos não ocorre no âmbito do
projeto, embora sejam administráveis pela equipe. Na maioria das vezes, os
mesmos são tratados em instâncias superiores. Com base nos fatores elencados
acima, foram observadas várias situações. De início, podemos citar o risco da
descontinuidade administrativa, uma característica bem peculiar ao setor público.
Este risco pode ter como consequências, mudanças nos direcionamentos da
 52

empresa, a suspensão de projetos e cortes orçamentários, eventos que afetam

diretamente os projetos e consequentemente, o programa.

Destaque também para o risco de um excessivo engessamento no processo

de tomada de decisões devido à burocracia, gerando impactos para o bom
funcionamento dos projetos. Observou-se a existência de um trâmite considerável,
passando por vários níveis da empresa até que certas definições ocorram. Um
exemplo é a dificuldade enfrentada no processo de definição pela adoção de um
software específico, quando algum departamento sugere a utilização de uma
ferramenta mais adequada, que traria melhores resultados e/ou produtividade no
processo de desenvolvimento do programa da empresa.

A burocracia, associada à distribuição geográfica, pode gerar riscos do

programa ter a qualidade de suas entregas comprometida. Podemos citar situações
onde se faz necessária a mudança em algum procedimento adotado dentro dos
projetos, por exemplo, uma solução para uma questão relacionada ao correto
funcionamento de uma funcionalidade implementada. Tal definição torna-se
demorada por necessitar ser discutida envolvendo os vários projetos e
departamentos relacionados ao assunto. Muitas vezes, por essa dificuldade, os
projetos avançam, convivendo com o problema, sendo sua solução adiada para um
momento futuro. Então, quando o problema começa a assumir proporções não
contornáveis, pela falta de tempo hábil para estudo e aplicação da melhor solução,
acaba sendo adotada uma solução intermediária que trará consigo algumas
consequências negativas.

Também foi observada a existência de processos políticos de tomada de

decisão. Uma situação afetada por este fato ocorre na definição de datas para a
entrega dos produtos. Em algumas situações, por fatores políticos, faz-se necessário
que a empresa apresente resultados. Resultados esses cuja concretização algumas
vezes não condiz com o cronograma exigido pelo processo normal de
desenvolvimento. Tal necessidade acaba acarretando no fechamento de prazos
muitas vezes tecnicamente inviáveis, gerando riscos de comprometimento da
qualidade das entregas produzidas. Outra situação também afetada pelo contexto
político é o fato da empresa XYZ iniciar alguns de seus projetos sem a assinatura da
respectiva declaração de escopo. Esse fato demonstra claramente a necessidade
dos projetos terem que se adaptar às realidades políticas e administrativas. Essa
 53

situação eleva o nível de risco do projeto, pois abre precedentes para que o cliente,
ao longo do tempo, faça solicitações que alterem o escopo inicial.

As restrições orçamentárias também configuram um fator gerador de riscos.

Sua ocorrência pode acarretar na impossibilidade de contratação de serviços ou
aquisição de ferramentas necessárias ao desenvolvimento das atividades. Por
contenção de despesas, os projetos poderão comprometer sua programação de
viagens para levantamento e validação dos requisitos junto ao cliente. As restrições
orçamentárias também são um fator presente em relação ao cliente. As equipes de
stakeholders destinados ao fornecimento de requisitos foram reduzidas, bem como o
tempo de dedicação dos mesmos a essa atividade e em alguns casos, o cliente é
compartilhado por vários projetos. Em consequência desses fatos, o processo de
levantamento, validação e homologação dos requisitos tem sido bastante
prejudicado. Isto configura um risco constante para o correto cumprimento dos
prazos dos projetos. Constatou-se pela mesma razão, e ainda agravado pelo fato
das equipes fornecedoras de requisitos serem provenientes de várias localidades do
país, a dificuldade para a realização de reuniões entre eles, com o objetivo de
discutir e amadurecer questões relacionadas ao negócio. Como consequência, os
requisitos são repassados aos projetos sem que os mesmos tenham sido
satisfatoriamente amadurecidos, gerando um número considerável de solicitações
de mudança posteriores. Em parte, com causa também nas restrições
orçamentárias, ocorre a troca de stakeholders fornecedores de requisitos, inserção
de novos stakeholders e a retirada de stakeholders chave no meio do processo. Os
novos stakeholders, por não estarem atualizados com relação a todo o trabalho
realizado até o momento, não terão uma atuação a curto prazo, dentro do nível
esperado e muitas vezes trazem à tona questões já discutidas anteriormente,
propondo mudanças para pontos cuja solução já foi definida. Esses fatos trazem
riscos de comprometimento da fase de levantamento de requisitos.

Uma característica peculiar das organizações reguladas pelo governo é a

descontinuidade do corpo executivo no nível estratégico; estes profissionais são
trocados a cada novo governo. Isto prejudica o desenvolvimento dos objetivos
estratégicos e, muitas vezes, impossibilita que o processo de planejamento
estratégico seja feito de forma contínua. Este fato configura um fator de risco,
 54

podendo acarretar em uma quebra no ritmo das atividades que vinham sendo
desenvolvidas até o momento.

A perda de recursos importantes para outros projetos acontece com alguma

frequência, devido a certos perfis serem escassos e a impossibilidade de
contratação imediata no mercado do tipo de mão de obra requerida, aumentando os
riscos de atrasos para o projeto.

A solução arquitetural atualmente utilizada no programa, por não estar

totalmente madura, dá margem à ocorrência de problemas ainda não solucionados;
gera constantes necessidades de alterações nos artefatos já implementados, o que
acarreta retrabalho instabilidade das funcionalidades já concluídas, atrasos e
desgastes junto ao cliente.

4.4 Integração

A integração visa promover o intercâmbio entre todas as áreas de

conhecimento e garantir que uma alteração em uma área seja refletida em todas as
outras que com ela tenham algum relacionamento.

A empresa XYZ, através do seu processo de desenvolvimento, já viabiliza a

integração a nível de projeto, contudo ainda não possui know-how para trabalhar
com programas. Quando focamos esse aspecto do programa ALFA, identificamos
que existe uma preocupação com a obtenção de bons resultados tanto na realização
da integração a nível do projeto quanto a nível do programa. O programa ALFA não
contou com os benefícios oriundos da utilização de um sistema integrado de
gerenciamento de projetos (SIGP) desde o seu início. A manutenção dos
cronogramas dos projetos era realizada na ferramenta Project, que se mostrou
inadequada para realizar o gerenciamento de programas, tornando a tarefa de
manutenção do cronograma bastante complexa.

A empresa conta com um escritório de projetos central e com um escritório

local, situado em cada uma das unidades de desenvolvimento (UD). Os escritórios
locais funcionam como um ponto de apoio aos projetos da UD, atuando na
orientação acerca da metodologia, das técnicas para estimativa do tamanho das
entregas, na utilização do SIGP. O escritório central é responsável por cerca de 75
projetos e atua na fiscalização dos mesmos.
 55

O processo de controle de mudanças é gerenciado pelo departamento de

produtos. As demandas dos clientes são por ele enviadas ao respectivo projeto, o
qual realizará a análise de impacto e as estimativas de custo e prazo. Essas
informações são devolvidas para o departamento de produtos, que definirá se a
demanda será atendida através de uma solicitação de mudança ou se dará origem a
um novo projeto.

A função de integração a nível do programa está sob a responsabilidade de

um projeto criado especificamente com essa função, denominado ALFA-GESTOR.
Este projeto atua no controle e coordenação do funcionamento dos projetos,
sincronizando cada cronograma de forma que os marcos possam ser cumpridos
dentro do esperado pelo cliente. Para realizar a integração técnica entre os projetos,
foi criado um outro projeto denominado ALFA-INTEGRADOR, que atua
estabelecendo padrões, coordenando atividades a serem realizadas nos projetos
para atender aos requisitos de padronização e otimização, além de realizar o
“merge” do código produzido pelos projetos para publicação em um portal único.

Diante do cenário desenhado, foi possível detectar com clareza a ocorrência

de dificuldades relacionadas à integração do programa ALFA:

 Planejar e cumprir o que foi estabelecido no cronograma geral, devido à

complexidade envolvida na sincronização das atividades de cada projeto
do programa.

 Devido à distribuição física dos projetos, foi observada uma dificuldade no

entendimento do funcionamento do programa como um todo, pela pouca
interação com os demais projetos envolvidos. Isso resultou na definição de
algumas soluções no âmbito de um projeto, que mais tarde se mostraram
ineficientes no âmbito do programa.

 Inexistência de uma cultura de aproveitamento das lições aprendidas

reportadas pelos demais projetos. Isso resulta na adoção de soluções ou
procedimentos que não obtiveram bons resultados no passado,
desperdiçando tempo e esforço.

 Observou-se um distanciamento entre o departamento de produtos e as

unidades de desenvolvimento (as quais se encontram mais alinhadas em
relação ao negócio por terem um contato mais frequente com o cliente).
 56

Isso tem se mostrado bastante prejudicial, pois a falta de conhecimento

por parte do departamento de produtos acerca das definições de negócio
que tem sido repassadas para as UDs sob a forma de requisitos acaba por
incapacitar o departamento de produtos na realização de negociações
junto ao cliente dentro de um nível desejável. A falta de acompanhamento
do departamento de produtos também faz com que o gestor de projeto se
envolva em questões que vão além das suas atribuições e do seu poder
de negociação (relacionamento com o cliente), fazendo com que o mesmo
perca o foco das atividades do projeto. Recentemente, na tentativa de
contornar tal situação, a empresa determinou a presença de um
funcionário do departamento de produtos em todas as reuniões
presenciais realizadas entre as UDs e o cliente. Contudo, pelo fato dessa
tentativa de acompanhamento ocorrer em uma fase adiantada do projeto
ou pela falta de conhecimento sobre o contexto dos projetos que estão
iniciando, por parte do departamento de produtos, foram observadas
dificuldades na atuação do mesmo como um aliado da equipe de projeto.

 A inexistência de um SIGP, desde o início do programa, teve como

consequências uma maior dificuldade no acompanhamento do andamento
do projeto/programa e falta de apoio no processo de tomada de decisões
antecipadas, pela carência de informações adequadas. Recentemente, a
empresa passou a adotar o Clarity como o SIGP a ser utilizado pelos
projetos. Contudo, devido ao pouco tempo de utilização, os recursos desta
ferramenta ainda não foram completamente explorados, portanto os
resultados obtidos com a sua utilização ainda não são totalmente
percebidos.

4.5 Comunicação

Segundo Prikladnicki & Audy (2007), o processo de desenvolvimento

distribuído de software depende largamente da comunicação entre os envolvidos no
projeto, seja de forma direta ou indireta. O programa ALFA possui como
característica marcante relacionada à comunicação, o fato de tanto as equipes de
projeto que compõem o programa, quanto as equipes do cliente responsáveis pelo
fornecimento de requisitos, encontrarem-se fisicamente distribuídas. Este fato faz
 57

com que os contatos presenciais requeiram a necessidade de realização de viagens.

As mesmas, apesar de viabilizarem uma melhor comunicação, apresentam como
desvantagem um alto custo para os projetos, além de consumirem um tempo extra
com os deslocamentos. Isto faz com que as viagens tornem-se escassas, obrigando
os projetos a utilizarem vários outros recursos no processo de comunicação. Dentre
os mais utilizados, podemos citar e-mails, videoconferências, telefonemas e correio
de mensagens instantâneas. Diante deste contexto, foram observadas várias
situações que dificultam as atividades do programa como um todo:

 Atualmente, cada unidade de desenvolvimento (UD) possui vários projetos

em andamento, tanto pertencentes ao projeto ALFA, como de outros
clientes da empresa XYZ. Para atender a toda essa demanda, cada UD
atualmente só conta com uma sala de videoconferência. Portanto, são
constantes os atrasos na definição de assuntos que requerem a realização
de reuniões deste tipo, a serem tratados com o cliente ou com outros
projetos, devido à dificuldade na obtenção de vagas nas salas de
videoconferência.

 A necessidade de utilização de meios alternativos de comunicação para

suprir a carência de contatos presenciais com o cliente e entre os projetos
dificulta bastante a execução de atividades como elicitação, validação e
homologação de requisitos, pois a comunicação presencial possibilita uma
maior facilidade de expressão das ideias, permite a percepção das
reações dos interlocutores, além de viabilizar a utilização de recursos
visuais como desenhos e gráficos.

 O programa não estabelece um cronograma de viagens, fazendo com que

as reuniões presenciais entre os projetos nem sempre contem com todos
os participantes necessários, resultando em prejuízos para os resultados
esperados com tais reuniões.

 O gestor é compelido a enviar frequentes e-mails reportando pendências

relacionadas ao projeto e informações referentes ao andamento do
mesmo, quando já existe um mecanismo de report semanal e mensal para
posicionamento sobre estas questões. Tal fato resulta em uma sobrecarga
para o gestor do projeto.
 58

 Observaram-se situações onde informações importantes foram

negligenciadas ou não informadas a todos os projetos a ela relacionados,
gerando erros e retrabalho no desenvolvimento das atividades.

 A distância física entre os projetos e entre os projetos e o cliente dificulta a

execução do gerenciamento das expectativas do cliente e a construção de
um relacionamento sólido. Quando não é possível a realização de viagens,
é necessária a utilização de outros recursos como a realização de
videoconferências, telefonemas e a troca de e-mails. Isso configura um
empecilho para que o gerente de projetos exerça sua liderança utilizando
suas habilidades pessoais, como por exemplo, carisma e empatia.

4.6 Tempo

Com a recente adoção de um SIGP, a empresa XYZ hoje tem acesso a

mecanismos mais eficazes de acompanhamento e controle dos seus projetos. A
ferramenta Clarity, utilizada atualmente, tem auxiliado na gestão dos cronogramas e
facilitado a visualização do programa como um todo sob a ótica do tempo. Neste
aspecto, observou-se que o processo de elaboração das estimativas das entregas
ainda não se encontra amadurecido. Em geral, tem havido uma diferença de tempo
bem considerável entre o prazo estimado e o realizado, configurando constantes
atrasos e desgastes junto ao cliente e à direção da empresa.

Verificou-se em algumas situações, uma falta de maturidade do cliente com

relação ao negócio. Antes mesmo da fase de codificação ser concluída, demandas
requerendo alterações são geradas. Tais demandas dão origem a solicitações de
mudança, as quais, para serem contempladas requerem retrabalho e alteram o
prazo final das entregas.

Observou-se que a ocorrência de atrasos em entregas onde existam

interdependências, potencializa com certa frequência, atrasos nos demais projetos
que dependem de tais entregas. Podemos citar também, em parte pela dispersão
geográfica, uma maior morosidade na resolução desses problemas que funcionam
como gargalos. Portanto, este efeito em cascata, acaba funcionando como um fator
multiplicador do atraso inicial.
 59

A indisponibilidade do cliente tem dificultado a realização de várias atividades.

Existem situações onde um mesmo cliente é compartilhado por vários projetos, o
que faz com que a qualidade das informações fornecidas seja comprometida. Além
disso, são constantes os atrasos na elicitação e validação de requisitos, bem como
na homologação das entregas.

A burocratização também foi observada como uma característica marcante

com impacto nos prazos dos projetos. Como exemplo, podemos citar o processo de
liberação para a realização de horas extras em um momento peculiar de um projeto.
Esse trâmite, em várias situações dificulta e às vezes até inviabiliza a finalização de
tarefas do projeto dentro do prazo esperado. Outro exemplo é a impossibilidade de
contratação de certos serviços ou aquisição de produtos necessários de forma ágil,
devido à necessidade de um processo licitatório.

A excessiva quantidade de reuniões relacionadas ao escritório de projetos,

aos demais projetos envolvidos, a problemas relacionados ao processo de
desenvolvimento e a questões envolvendo o cliente, muitas vezes demandam a
presença de outros membros da equipe, além do gestor do projeto. Isso provoca a
quebra do ritmo do projeto, algumas vezes se refletindo em atrasos no cronograma.

Detectou-se a inexistência de um cronograma de viagens do programa,

fazendo com que:

 O gestor perca o foco do projeto para cumprir as atividades relacionadas

ao motivo da viagem;

 As atividades relacionadas ao motivo da viagem não tenham sido

contempladas no cronograma;

 As tarefas rotineiras do projeto sejam colocadas em segundo plano, pelo

fato da comunicação de tais viagens geralmente ocorrerem de forma
repentina;

 O acúmulo de ocorrências desse tipo de atividade gere a necessidade de

repactuação do cronograma do projeto.

Detectou-se a falta de definição de indicadores adequados para acompanhar

a evolução de cada um dos projetos do programa. Atualmente não faz parte da
cultura da empresa fazer avaliações do progresso dos projetos baseada em
 60

indicadores. Essa é uma inovação que está sendo iniciada durante a execução do
programa. Os indicadores atualmente definidos ainda não foram refinados e também
não são suficientes para uma análise mais apurada.

A empresa ainda não possui uma base de conhecimentos, a qual poderia

fornecer subsídios que proporcionassem uma estimativa mais acertada de duração
das atividades e uma melhor definição dos indicadores citados no parágrafo anterior.

Os cronogramas dos projetos são elaborados sem a previsão para

treinamentos. Ao longo do projeto, a empresa divulga a realização de vários tipos de
treinamentos e o gestor do projeto libera seus integrantes para realização dos
mesmos de acordo com os respectivos perfis. Portanto, durante a execução do
projeto, o tempo utilizado para a realização dos treinamentos reflete nos
cronogramas como atraso.

Uma das premissas do programa é a disponibilidade dos clientes técnicos

para o fornecimento e validação dos requisitos. Quando essa premissa é quebrada
por parte do cliente, o ônus é revertido para o projeto em forma de atraso.

Na elaboração dos cronogramas não foi levado em conta o plano de

gerenciamento de riscos. Podemos citar, por exemplo, a inexistência de reservas de
contingência, com o objetivo de contornar situações onde um ou mais riscos
levantados venham a se concretizar.

4.7 Escopo

A coleta dos requisitos ocorre na maioria das vezes em reuniões presenciais

realizadas com a participação do cliente, e geralmente com a presença do
responsável por requisitos e do gestor do projeto. Usualmente é realizada através de
entrevistas com a utilização de protótipos. Em alguns casos, a coleta de requisitos
pode ser complementada através de videoconferências, quando há concordância
por parte do cliente. É importante salientar que nem toda a equipe de especificação
participa da coleta de requisitos, precisando que posteriormente seja realizado
repasse pelo gestor do projeto, responsável por requisitos ou pelos demais
especificadores que participaram do levantamento.

A empresa encontra-se em fase inicial de utilização da ferramenta Caliber.

Contudo, os benefícios por ela oferecidos na fase de coleta de requisitos não são
 61

usufruídos, pois isso implicaria em um oneroso processo de conversão de toda a

documentação já elaborada referente ao programa ALFA.

A verificação do escopo ocorre ao final de cada iteração. Ela se dá com a

homologação das funcionalidades daquela fase pelo cliente, através da execução de
testes baseados em roteiros construídos pela equipe do projeto. Este processo é
acompanhado geralmente pelo gestor do projeto, pelo responsável por requisitos,
podendo contar também com outros integrantes da equipe.

Para as entregas aprovadas, é gerado um termo de aceite. Dependendo dos

apontamentos realizados pelo cliente durante a homologação, poderão ser geradas
uma ou mais solicitações de mudança.

O controle do escopo ainda não é realizado de um modo sistemático, de

forma a possibilitar a tomada de ações preventivas, minorando o impacto de
algumas ocorrências. No levantamento inicial do escopo o cliente define todas as
funcionalidades que ele acha que serão necessárias. Com o avanço da execução do
projeto e já sendo possível mostrar parte do produto ao cliente, normalmente, nesse
momento o cliente consegue visualizar que a definição do escopo não está
completa, identificando a necessidade de novas funcionalidades, as quais não
estavam previstas no escopo inicial.

Algumas dependências entre os projetos não foram levadas em conta, o que

fez com que erros tenham sido cometidos no processo de distribuição geográfica
dos mesmos, alocando em unidades de desenvolvimento diferentes, projetos com
um alto nível de integração.

Observaram-se situações em que pelo processo de definição do escopo

acontecer no âmbito de cada projeto e devido a uma comunicação insuficiente entre
os projetos, intensificada pela falta de maturidade no trabalho em programa,
entregas bem semelhantes foram solicitadas a projetos distintos. Ainda pelas
mesmas razões, podemos citar ocasiões em que um projeto acaba avançando na
fronteira de outros com os quais tenha alguma integração.
 62

5. PESQUISA

Este capítulo tem como objetivo explanar como foi o planejamento, a

elaboração, execução e a análise da pesquisa aplicada, adotada neste trabalho
como uma forma de identificar os níveis de maturidade organizacional e dos
gestores em relação às práticas de gerenciamento de projeto.

5.1 Contextualização

Segundo Kerzner (2004), a maturidade em gestão de projetos é o

desenvolvimento de sistemas e processos que são por natureza repetitivos e
garantem uma alta probabilidade de que cada um deles seja um sucesso.

Ainda segundo Kerzner (2004, p.45):

Quando as empresas desenvolvem sistemas e processos maduros,

surgem dois benefícios adicionais: primeiro, o trabalho é executado
com o mínimo de mudança de escopo; segundo, os processos são
definidos de maneira a causarem o mínimo de problemas para o
negócio principal da empresa.

Para Soler (2005), apesar de não ser garantia absoluta de sucesso, um nível
maior de maturidade na utilização de técnicas de gerenciamento de projeto aumenta
significativamente as chances de sucesso do projeto ao traduzir estratégias de
negócio em resultados de sucesso, consistentes e previsíveis.

Pelo exposto podemos perceber o quanto a maturidade na utilização das

práticas de gerenciamento de projetos é importante para que os projetos e
programas da empresa tenham um elevado grau de sucesso.

Uma maneira comum de determinar o nível atual de capacidade e maturidade

de gerenciamento de projeto de uma organização é usando o portifolio, programme
and project management maturity model, que é composto de cinco níveis, como
pode ser visto na Figura 5.1.

A fim de obter informações sobre esta maturidade na empresa, foi elaborada

uma pesquisa aplicada, composta de questionários e cujo resultado principal
determina o nível de maturidade que a empresa XYZ se encontra, tendo como
referência os níveis definidos no P3M3 e exibidos na Figura 5.1.
 63

Figura 5.1 – Níveis de Maturidade do P3M3

5.2 Universo amostral e amostra

O Universo amostral da pesquisa foram os gestores de projeto do programa

ALFA, que é o alvo do estudo deste trabalho.

Por questões de acessibilidade, a amostra escolhida deste universo foi não

probabilística e correspondeu aos gestores de projeto do programa ALFA que
trabalham na unidade de desenvolvimento do Ceará. Dentro desta amostra, foram
convidados a participar gestores de perfis variados, sendo eles de vários projetos do
programa, homens e mulheres, jovens e adultos, buscando assim uma boa
representação na pesquisa.

5.3 Formatação da Pesquisa

A pesquisa foi dividida para que pudéssemos identificar e analisar de forma

separada de um lado a maturidade dos processos utilizados pela empresa e de
outro o nível de conhecimento e experiência dos gestores. Baseando-se nesta
decisão, foram elaborados dois questionários estruturados, no formato múltipla
escolha, hospedados em um sítio da WEB, que registravam automaticamente as
respostas em uma planilha. A forma de registro automático permitiu manter o
 64

anonimato dos participantes, de modo a não produzir qualquer constrangimento a

eles e assim gerar respostas mais confiáveis.

5.4 Definindo questionários de maturidade personalizado

Atualmente existem vários modelos de questionários que se destinam a

avaliar o nível de maturidade na utilização das boas práticas de gerenciamento de
projeto. Para este estudo decidiu-se construir um modelo personalizado que
pudesse abranger as áreas de conhecimento definidas no PMBOK e destacar os
fatores críticos do programa ALFA, explicitados na fundamentação teórica deste
documento.

O modelo P3M3 foi escolhido como base para o estudo de maturidade deste
trabalho por ser um modelo de maturidade baseado nas boas práticas de mercado e
utilizado amplamente na avaliação de maturidade das organizações em relação à
utilização das boas de gerenciamento. O P3M3 é um modelo que possibilita a
análise de Portfólio, Programas e Projetos e que realiza seu diagnóstico (ou auto
diagnóstico) com base nos cinco níveis de maturidade descritos na figura 5.1.

Outro motivo para sua adoção é que o P3M3, como indica seu guia de
utilização, é bastante flexível e pode ser refinado ou expandido de acordo com as
necessidades específicas do gerenciamento do projeto, programa ou portfólio em
questão.

O trabalho em relação ao questionário personalizado para este trabalho foi

justamente adaptar os princípios descritos no modelo P3M3 para focar nos conceitos
chave de gerenciamento de projeto e programa, mais relevantes em relação ao
programa ALFA e aos valores organizacionais da empresa XYZ. Deste modo, a
elaboração dos questionários customizados levou em consideração não somente os
vários modelos de questionário disponíveis no mercado e as questões clássicas
ligadas à restrição tripla, mas buscou investigar conceitos e questões ligadas ao
desenvolvimento distribuído de software e ao fato da execução do programa ser feito
por uma empresa pública de TIC.

O primeiro questionário focava em questões que tratavam da maturidade da

empresa em relação às práticas de gerenciamento de projetos. Possuía um total de
60 questões, distribuídas entre as nove áreas de conhecimentos elencadas pelo
 65

PMBOK e assuntos relacionados ao processo de gestão, com perguntas envolvendo

processos, artefatos e metodologia. Este questionário teve como base um
questionário similar utilizado na disciplina de “Project Office e nível de maturidade”
onde foram acrescentadas questões consideradas relevantes tendo em vista os
objetivos da pesquisa.

O segundo questionário tratava de questões sobre o conhecimento e as

experiências individuais dos gestores. Possuía um total de 20 questões, que
abordavam conhecimentos teóricos, práticos e resultados obtidos em gerência de
projeto.

Para cada questionário, o entrevistado deveria selecionar uma única

alternativa por questão, que continham itens com valores variando de zero a cinco.
Os valores representavam o nível de aplicação das práticas ou o nível de
conhecimento/experiência sobre o assunto abordado.

O tempo médio de resposta para os dois questionários oscilou em torno de

quinze minutos.

5.5 Limitações

Durante a elaboração dos questionários, a primeira dificuldade encontrada foi

selecionar um grupo de perguntas que fosse significativo, mas que não tornasse os
questionários grandes, pois se isto acontecesse poderia ficar inviável aplicá-los.

Outra limitação importante foi na definição da amostra da pesquisa aplicada.

Inicialmente estávamos planejando aplicar os questionários em gestores de projetos
do programa ALFA que trabalhassem em todas as unidades de desenvolvimento
envolvidas: Ceará, Santa Catarina e Rio de Janeiro.

Diante da dificuldade de mobilização dos gestores de Santa Catarina e do Rio

de Janeiro e do risco inerente de atrasos, decidiu-se restringir a escolha dos
voluntários ao grupo de gestores de projeto do programa ALFA que trabalham na
unidade do Ceará, com sede em Fortaleza.

Mesmo dentre estes escolhidos, houve alguns imprevistos por conta de

viagens e treinamentos que impossibilitaram que a coleta de dados seguisse o
cronograma inicialmente estabelecido.
 66

O fato de o programa ALFA estar em fase de homologação, já se preparando

para entrar em produção, também trouxe algumas limitações, pois a aplicação dos
questionários tinha prioridade baixa em relação às demais atividades dos gerentes
de projeto convidados a participar da pesquisa.

5.6 Análise dos resultados

5.6.1 Técnica de análise e interpretação de dados

O método de análise dos resultados utilizado levou em consideração as

medidas estatísticas de tendência central: Moda e Média e as medidas de dispersão:
desvio padrão e coeficiente de variação. Medeiros (2007) nos dá as seguintes
definições acerca dos conceitos e das medidas estatísticas que vamos utilizar:

 Média é um valor típico de um conjunto de dados que tende a se localizar em

um ponto central.
 Moda é o valor que ocorre com maior freqüência, isto é, o valor mais comum.
 Dispersão (ou variabilidade) de um conjunto indica a maior ou menor
diversificação dos valores de uma variável em torno de um valor de tendência
central tomado como ponto de comparação.
 Desvio padrão é a medida da variação, da dispersão, de um conjunto.
 Coeficiente de Variação é uma medida voltada para caracterizar, em termos
relativos, o grau de dispersão dos conjuntos.

Foram determinados os níveis de maturidade da empresa e dos gestores,

através de faixas de valores pré-determinadas que indicavam um nível de
maturidade específico. Utilizando as medidas citadas acima, pôde-se observar que o
nível de dispersão do questionário de maturidade empresarial foi baixo. A média
aritmética e a moda do conjunto de respostas apresentaram o mesmo valor.
Concluímos assim que a amostragem escolhida foi bastante equilibrada, ou seja,
não houve grande variação nas respostas dos colaboradores neste questionário.
Acredito que isto demonstre uma boa veracidade nas informações sobre a empresa.
Podemos ainda inferir que a metodologia de gerenciamento de projetos, apesar de
ter suas limitações, já está bem institucionalizada na empresa.

5.6.2 Análise dos questionários

As faixas de valores de maturidade no modelo em questão, assim como no

P3M3, variavam de zero a cinco. A maturidade da empresa em relação às práticas
 67

de gerenciamento de projetos, obtida com o resultado da pesquisa, foi nível 3.

Seguindo a classificação do P3M3, isto significa que o processo de gerenciamento
de projetos na empresa XYZ já está definido, ou seja, existe uma metodologia única
utilizada por praticamente todos os projetos da empresa.

Alguns pontos positivos e negativos nos chamaram a atenção nos resultados,

e foram observados pelos valores próximos dos extremos ou pelo desvio
apresentado entre as respostas.

5.6.3 Questionário sobre a maturidade da empresa

5.6.3.1 Quesitos com destaque positivo (Alta maturidade)

Em relação à designação do gerente na fase de autorização do projeto, 90%

das respostas indicam que a designação realmente ocorre nesta fase para a maioria
dos projetos da empresa (níveis 4 e 5). A alocação do gerente antes mesmo da
formalização do projeto permite que seja feito um planejamento inicial que possa
fornecer informações de maior qualidade para o processo de autorização. Outra
vantagem é que este planejamento inicial será detalhado pela mesma pessoa ou
equipe que o concebeu. Para este item, podemos destacar ainda que os valores de
média e moda foram iguais e que o desvio padrão e o coeficiente de variação
apresentaram uma dispersão baixa entre as respostas.

Sobre o plano de projeto, observou-se que em 70% das respostas houve

indicativo de que este artefato é mantido atualizado pelos projetos. Podemos
concluir com isto que o planejamento do projeto é constantemente avaliado e
atualizado em boa parte dos projetos do programa ALFA, o que possibilita uma
confiabilidade maior das informações disponibilizadas para os stakeholders.

Quanto à existência de um escritório de projetos atuante, 60% das respostas

indicam nível 4 ou 5, demonstrando a alta maturidade neste quesito. O coeficiente
de variação ficou em torno de 26%, indicando uma dispersão média nas respostas o
que aponta que este escritório não deve atender todos os projetos de forma igual,
priorizando os mais críticos e fornecendo para estes um melhor atendimento.

No que se refere à utilização de um sistema integrado de gerenciamento de

projetos (SIGP), 60% das respostas indicam que os projetos utilizam um SIGP. Uma
 68

informação importante é que todos os novos projetos da empresa serão obrigados a

utilizar esta ferramenta, o que com que este índice cresça ao longo do tempo.

Figura 5.2 – Distribuição da maturidade na validação da EAP e declaração de escopo.

No item que aborda a validação da EAP e declaração de escopo pelos

principais stakeholders, em pelo menos 55% das respostas verificamos que a
maturidade se encontra nos níveis 3 ou 4. Esta informação é bastante relevante uma
vez que a validação destes artefatos é fundamental para a redução das solicitações
de mudança de escopo durante o ciclo de vida do projeto. Na figura 5.2 podemos
observar a distribuição dos níveis de maturidade em relação a este quesito, com
destaque para o total dos níveis 3 e 4.

Apesar do índice alto de projetos que tem sua declaração de escopo assinada
pelos principais stakeholders, acredito que esta assinatura muitas vezes não
aconteça logo no início do projeto, como denotam os resultados de outra questão
que abordaremos posteriormente. O fato de que a empresa e seus principais clientes
são empresas públicas, pode justificar o problema citado.

Quanto à alocação da equipe em tempo integral, 90% das respostas indica

níveis altos de maturidade (4 ou 5), mostrando que este procedimento já é adotado
na maioria absoluta dos projetos da empresa. Esta informação pode ser confirmada
por experiência própria, onde percebi que a alocação parcial só acontece durante a
fase inicial das transferências de analistas entre projetos ou em caso de força tarefa
para auxiliar algum projeto em dificuldade. As respostas a este quesito tiveram um
baixo índice de dispersão (11%) e baixo desvio padrão (0,52), o que indica uma forte
institucionalização do procedimento.
 69

Na figura 5.3 podemos ver estes números exibidos em sua forma Gráfica.

Figura 5.3 – Distribuição dos níveis de alocação da equipe em tempo integral.

No que diz respeito ao uso de uma metodologia unificada de gerenciamento

de projeto, observamos que a média do nível de maturidade ficou em 4, sendo que
50% das respostas indicam níveis 4 ou 5 (uso do processo pela maioria dos
projetos). Ainda há espaço para o crescimento deste percentual, principalmente se
forem feitos ajustes na metodologia para tratar de forma diferenciada projetos de
diferentes portes.

Sobre as avaliações de qualidade por equipe externa, tanto a média quanto a

moda apontam para o nível 4, indicando que este processo ocorre para quase todos
os projetos da empresa. Neste caso, 80% das respostas indicam índice 4 ou 5 e
todas as respostas tiveram valor igual ou superior a 3.

Ainda se tratando da qualidade, verifica-se que em relação à realização de

auditorias frequentes, as respostas do questionário apontam para média 4, sendo
que 70% dos gestores responderam com níveis 4 ou 5. Esta informação nos permite
concluir que a equipe de qualidade é fortemente atuante nos projetos.

Outra informação importante é que em 80% das respostas, percebemos a

indicação de um mecanismo de controle das não conformidades encontradas nas
auditorias. Isto faz com que os desvios ao processo e os defeitos dos sistemas
possam ser categorizados e documentados, servindo tanto para registrar as
soluções aplicadas quanto para evitar que os problemas sejam repetidos no futuro.
 70

Todos estes fatores citados são importantíssimos no processo de

desenvolvimento de sistemas, e mais ainda se considerarmos a distribuição
geográfica dos projetos e o fato da execução ser realizada por uma empresa
pública, mas apesar de todos estes fatores positivos, entendemos que as avaliações
de qualidade hoje focam muito no processo de desenvolvimento e pouco no produto
gerado. Isto faz com que a relevância dessas auditorias seja menor do que poderia
ser e que o cliente não consiga enxergar a contribuição do processo de qualidade
para o melhor funcionamento do produto gerado pelos projetos.

Referente aos acordos de nível de serviço (ANS) serem definidos em contrato

com o cliente, foi verificado que 70% das respostas indicaram níveis 4 ou 5. Vale
registrar que os demais 30% apontaram níveis 1 ou 2, mostrando que ainda existem
variações por projeto ou problemas na divulgação da informação de contratos para
os gestores. Ter visibilidade do ANS dos sistemas produzidos é imprescindível para
desenvolver documentação e código que permitam o atendimento nos tempos
acordados com o cliente.

Sobre o registro das lições aprendidas, pode-se constatar que a média das
respostas aponta para o nível 4, sendo baixo o desvio padrão (0,94) e médio o
coeficiente de variação (24%). Estes números apontam para o fato da maioria dos
projetos já estarem fazendo o registro das lições aprendidas, mas que alguns ainda
apresentam dificuldades em executar o registro.

5.6.3.2 Quesitos a serem desenvolvidos (Baixa maturidade)

Em relação à assinatura da declaração de escopo, apesar da mesma ser

assinada para a maioria dos projetos, 70% das respostas apontam uma assinatura
tardia da mesma, após a criação do projeto e muitas vezes após algumas entregas.
Isto é um risco imenso para os projetos, pois sem a declaração de escopo validada
pelo cliente, as mudanças no escopo podem inviabilizar a entrega do projeto de
acordo com a linha de base de tempo e custos.

Quanto ao projeto ter um patrocinador ciente das suas obrigações,

verificamos que em 50% das respostas encontramos valores que indicam
maturidade abaixo de 3. Consideramos este resultado muito desfavorável uma vez
que os projetos são desenvolvidos em um ambiente bastante influenciado por
 71

decisões políticas e a inexistência de um patrocinador ou a falta de ciência deste das

suas obrigações, faz com que o projeto fique muito vulnerável às influências
negativas do ambiente onde é desenvolvido.

Outra questão cujas respostas reforçam o risco de mudança durante o projeto

é se as alterações nas linhas de base do projeto são previamente analisadas e
aprovadas por um comitê de controle de mudanças. As respostas apontam para
níveis baixos de maturidade em 80% dos casos. Neste caso tivemos valor de média
igual a 2 e moda igual a 1. Disto podemos concluir que alguns poucos projetos tem
um comitê de controle de mudança atuante. Na maioria dos casos este comitê
sequer existe ou é incipiente. A figura 5.4 mostra graficamente a distribuição das
respostas. Nesta figura foi dado um destaque à soma dos níveis 0, 1 e 2, de forma
que ficasse claro o percentual que estes níveis juntos representam em relação ao
total de respostas do quesito.

Figura 5.4 – Distribuição dos níveis de maturidade pra aprovação prévia das alterações nas linhas de
base dos projetos.

As respostas da pergunta que investiga se as equipes dos projetos tem

treinamento nas práticas de gerenciamento de projeto evidenciaram uma situação
preocupante e desfavorável para os processos de gerenciamento de projetos da
empresa. Em 80% dos casos, os níveis indicados foram 0 ou 1. Isto significa que as
equipes não tem treinamento nas práticas de gerenciamento de projeto ou os
treinamentos são esporádicos e pontuais. Esta situação, além de dificultar o trabalho
dos gestores de projeto, faz com que o processo de renovação e substituição de
gestores se torne bem mais difícil.
 72

Analisando a questão das revisões periódicas do escopo, para verificar se o

mesmo ainda atende as necessidades dos stakeholders, as respostas apontam para
um cenário onde a revisão não é feita ou é feita de forma eventual. A falta dessas
revisões pode fazer com que os projetos tenham problemas no momento da
homologação dos sistemas e das respectivas aceitações dos produtos pelos
clientes. Neste quesito apenas 40% das respostas indicaram nível 3 ou superior.

Ainda em relação ao escopo, a pesquisa indica que nem especialistas nem

projetos anteriores (similares) são consultados para a definição do escopo de um
novo projeto. Apenas em 30% das respostas houve indicativo que algo neste sentido
era feito. Este cenário é desfavorável, mas está mudando para melhor. Nos novos
projetos, é o departamento de produto e o cliente que fazem a primeira proposta de
escopo. Baseado neste documento é que a equipe do projeto irá gerar a versão
inicial da declaração de escopo que por sua vez deverá aprovada pelo cliente antes
do início do projeto.

Referente às questões de gerenciamento de custos e gerenciamento de

aquisições, todas tiveram uma pontuação baixa, com média igual a 1. Este resultado
já era esperado, uma vez que na empresa XYZ existe um departamento que
centraliza todo o controle de custos, inclusive os custos referentes às equipes de
projeto. Esta estratégia empresarial afeta não só o gerenciamento de custos, mas
também o gerenciamento de tempo, uma vez que sem saber os custos do projeto, o
mesmo não consegue calcular o valor agregado das tarefas e fica impossível usar a
técnica de valor agregado para indicar os índices de desempenho de tempo e de
custo. A confirmação disso é facilmente encontrada na pergunta que indaga sobre o
uso da técnica de valor agregado (Earned Value) e que teve em média nível 1. Este
resultado é plenamente justificável pelo fato da técnica não ser adotada
institucionalmente na empresa pelos motivos já citados.

Outro reflexo dessa centralização no controle de custos é a ausência de

reservas gerenciais e de contingência. Esta realidade é evidenciada por 90% das
respostas do quesito que investiga este assunto e que comprova a realidade da
empresa. Quando ocorre a necessidade de acionar uma reserva, o gerente de
projeto tem sempre que escalar a questão para seus superiores. A falta da mínima
possibilidade de decisão financeira e orçamentária do projeto prejudica o tratamento
 73

de riscos e muitas vezes inviabiliza a implementação de uma mitigação para os

mesmos.

Em outra questão relacionada ao gerenciamento de riscos, pôde-se constatar

que os principais stakeholders não são orientados em relação aos riscos do projeto,
em especial o cliente, que não tem nenhuma visibilidade sobre os riscos e não pode
ajudar nas ações de mitigação e contingência. Em 70% das respostas esta situação
é evidenciada na nossa pesquisa.

Sobre as questões de maturidade da empresa, o último ponto onde se

observa necessidades mais sérias de melhoria é no reuso das lições aprendidas.
Vimos na seção anterior que a maioria dos projetos já registra as lições aprendidas,
mas o que adianta fazer o registro se estas lições aprendidas não são usadas no
planejamento dos novos projetos? Este é o desafio que a empresa XYZ terá que
superar para alterar o que 90% das respostas apontaram como um processo falho.

5.6.4 Questionário sobre a maturidade dos gestores

5.6.4.1 Quesitos com destaque positivo (Alta maturidade)

Uma análise geral das respostas do questionário de maturidade dos gestores

indica média 3 de conhecimento. Das médias das perguntas realizadas, 80% tiveram
respostas iguais ou superiores a esta média geral. Estes números indicam um bom
grau de conhecimentos dos atuais gestores do programa ALFA em relação à gestão
de projetos.

As perguntas que investigavam o conhecimento teórico dos gestores em

gerência de projetos e o conhecimento nas práticas de gerencia de projetos
abordadas pelo PMBOK tiveram pontuação alta. Uma média 4 em nossa escala que
vai de 0 a 5. Para estas perguntas, os valores de média e moda foram iguais, o que
aponta para uma amostra bastante homogenia em relação a estes quesitos.

Dentre as áreas de conhecimento abordadas pelo PMBOK, as que tiveram

maior pontuação em relação ao conhecimento dos gestores foram as áreas de
gerência de tempo e de comunicação. Não por coincidência, estas são duas das
áreas mais críticas no programa ALFA tendo em vista as cobranças constantes da
alta administração, dos “prazos políticos” e do desenvolvimento distribuído entre
 74

várias unidades da empresa XYZ (Ceará, Rio de Janeiro e Santa Catarina). Um fator
que torna a gerência de comunicação ainda mais importante é que o cliente está
localizado em Brasília, uma localização física diferente de todas as unidades de
desenvolvimento envolvidas no programa. Sabendo que o grau de conhecimento
dos gestores nas áreas de Gerencia de Tempo e Gerencia de Comunicações teve
média 4, podemos concluir que existe um esforço dos gestores para conhecer e
dominar os processos das áreas mais críticas para o programa.

Outra questão que chama atenção é a que trata do grau de conhecimento

sobre feedback. No início do ano passado, os gerentes de projeto da unidade de
desenvolvimento do Ceará tiveram um treinamento sobre feedback e esta prática
melhorou bastante naquele momento. Com o passar do tempo a prática do feedback
foi sendo esquecida uma vez que não se enraizou o suficiente na cultura do grupo.
Ao perceber isto foi aplicado um segundo treinamento para reforçar a importância do
feedback e nivelar o conhecimento sobre ele. A pesquisa foi aplicada logo após este
treinamento e as respostas refletem os seus efeitos. A média das respostas para a
pergunta sobre feedback mostrou um nível de conhecimento igual a 4. A moda
também foi 4 e os valores de desvio padrão e coeficiente de variação deram baixos.

Um último quesito, que teve uma média alta, investigou o grau de liderança
que os gestores tinham em relação a sua equipe, levando em consideração seus
conhecimentos e suas características pessoais. A média das respostas foi 4,
indicando que os líderes acreditam que estão exercendo sua liderança de forma
eficiente. Infelizmente não existia uma avaliação 360° das equipes que pudesse
comprovar estes números, desta forma foi necessário basear a análise nas
respostas que os gestores forneceram na pesquisa.

5.6.4.2 Quesitos a serem desenvolvidos (Baixa maturidade)

Uma primeira observação em relação ao conjunto de respostas do

questionário de maturidade individual dos gestores é que na maioria das perguntas o
desvio padrão e o coeficiente de variância tiveram valores altos, indicando que o
grupo de gestores do programa ALFA é bastante heterogêneo, possuindo gestores
experientes, com bastante conhecimento conceitual e prático e gestores neófitos,
sem formação em gestão, nem muita experiência na matéria. Isto nos remete ao
efeito halo, onde os técnicos que se destacaram em seu trabalho são promovidos
 75

aos cargos de gestão. Isto ocorre com frequência na empresa XYZ, sobretudo pela
falta de um programa de preparação de novos gestores. Pela ausência de um “time
reserva”, o responsável pela unidade de desenvolvimento promove os seus
melhores técnicos a gestores, na esperança que os mesmos também tenham um
bom desempenho como gestores de projeto.

Analisando as questões individualmente, podem ser destacados cinco pontos

que denotam as áreas de conhecimento que mais devem ser trabalhadas nos cursos
oferecidos pela empresa XYZ e no acompanhamento constante que o escritório de
projetos faz em relação aos gestores.

O primeiro destes pontos se refere à área de conhecimento de Gerência de

Qualidade. Apesar de existir uma equipe de qualidade atuante, está parecendo que
os projetos estão delegando para este grupo toda a responsabilidade sobre o
processo de qualidade dos projetos. Em 40% das respostas, os gestores indicaram
conhecimento insuficiente nesta área, sendo a moda do quesito igual a 2. Acredita-
se que este resultado se deve à pressão por prazos que leva os projetos a
“terceirizarem” os cuidados com a qualidade do processo e do produto,
sobrecarregando a área da empresa encarregada da aferição da qualidade.

Outras duas áreas que tiveram pontuação baixa foram as áreas de Gerência
de Custos e de Gerência de Aquisições. Estes valores já eram esperados pelos
mesmos motivos apontados no questionário de maturidade da empresa. Como a
empresa XYZ é de gestão pública, o controle de custos, bem como as aquisições
externas, são centralizados em setores específicos que não tem muita interação com
os projetos. As aquisições internas muitas vezes também não são comandadas
pelos gestores, por conta de termos uma estrutura hierárquica do tipo matricial fraca.
A consequência prática destes fatores é que os gestores de projeto necessitam
constantemente da intervenção do gerente funcional nas negociações das
aquisições e esta prática ficou refletida na pesquisa como falta de conhecimento nas
áreas apontadas.

Outro quesito importante que teve uma média baixa foi sobre a conclusão dos
projetos dentro do custo orçado. Esta questão ficou um pouco prejudicada pela
ausência de dados precisos nos projetos, mas mesmo em uma análise menos
detalhada fica evidente que os orçamentos são estourados, chegando em alguns
caso a gerar prejuízo para a empresa.
 76

Para finalizar esta análise, um ponto que tem causas variadas e que é comum
aos projetos empreendidos não só na empresa XYZ em várias empresas que
trabalham com projetos é a conclusão dos projetos em um prazo superior ao
estimado. Um estudo sobre os motivos dos atrasos e o gerenciamento de riscos
necessários para minimizá-los é um tema complexo o suficiente para gerar um TCC
somente sobre ele. Neste momento será apontada apenas a pressa para a definição
de escopo e para a criação do planejamento inicial do projeto, combinada com a
imaturidade do cliente em relação ao objetivo do projeto e com os fatores políticos
como causas suficientes para justificar os atrasos. De qualquer forma, independente
dos motivos, 80% dos gestores vem convivendo com atrasos no cronograma e
estouros nos orçamentos dos seus projetos. Estes números são bastante
significativos e o escritório de projetos da empresa XYZ terá que trabalhar junto com
os gestores e os órgãos de apoio para reduzi-los.
 77

6. CONCLUSÕES

6.1 Conclusões individuais de Adilton Ribeiro de Souza

O objetivo deste trabalho foi apresentar uma análise de um caso de

gerenciamento de projetos de software distribuído em uma organização do setor
público brasileiro, com base no PMBOK. Para tanto, foi tomado como exemplo o
programa ALFA da empresa XYZ, que atualmente está em fase de homologação. A
ideia básica era apresentar um panorama geral da situação atual dos projetos na
organização e, uma vez que a mesma tenha sido compreendida, investigar
estratégias para melhoria desse cenário. Foram apresentadas duas visões desta
situação: uma visão subjetiva e a visão dos gestores da organização, obtida a partir
de uma pesquisa.

Apesar de ser um fenômeno relativamente recente, o gerenciamento de

projetos é uma realidade cada vez mais presente no dia-a-dia de muitas
organizações. Além de proporcionar vários benefícios, pode-se afirmar que esta
abordagem é necessária para que as organizações possam atender a demandas
cada vez mais complexas de clientes cada vez mais exigentes. Não pode se dizer,
entretanto, que o gerenciamento de projetos é capaz de fazer com que todos os
projetos de uma organização venham a ser bem-sucedidos. Conforme foi
apresentado, a definição de sucesso é bastante relativa e pode levar em
consideração a visão estratégica da organização.

As organizações do setor público estão focando na melhoria da prestação dos

serviços à sociedade que, por sua vez, tem sido cada vez mais exigente e
participativa. Isto tem impulsionado investimentos no segmento de TI no setor
público. Este, por sua vez, vem desenvolvendo projetos de forma a atender às
demandas da sociedade, utilizando as técnicas de gerenciamento de projetos. Como
foi visto, os projetos do setor público tendem a ser mais complexos que os projetos
do setor privado, inclusive os projetos de software.

Outra tendência que tem sido observada de forma crescente nas

organizações é o desenvolvimento distribuído de software. Esta prática apresenta
alguns benefícios, dentre os quais a distribuição da complexidade e a diminuição de
 78

custos. Contudo, esta abordagem apresenta muitos desafios e precisa ser muito
bem planejada e trabalhada, sobretudo em organizações do setor público.

O programa ALFA, demandado pelo principal cliente da empresa XYZ, tem

como objetivo a modernização do sistema de benefícios da previdência e assistência
social brasileira, por meio do desenvolvimento de um software no formato de portal,
constituído por diversas funcionalidades. O programa possui 18 projetos, distribuídos
geograficamente entre as unidades de desenvolvimento da empresa XYZ lotadas
nos estados do Ceará, Rio de Janeiro e Santa Catarina, reproduzindo o modelo de
negócio de DDS chamado de onshore insourcing.

As análises apresentadas acerca do programa ALFA permitiram uma

visualização resumida de um cenário com problemas característicos de DDS, assim
como problemas específicos de organizações públicas. Embora alguns problemas
tenham origem na cultura organizacional do setor público, as boas práticas de
gerenciamento de projetos enumeradas no PMBOK podem contribuir positivamente
para diminuir a incidência de alguns dos problemas apresentados. A partir de agora,
discorrerei a respeito de alguns dos problemas observados, apontando sugestões
sempre que possível e eventuais constatações.

O planejamento das comunicações é uma boa prática instituída pelo PMBOK

e deve levar em consideração a utilização de ferramentas e tecnologias compatíveis
com a demanda de informação que deverá ser recebida e distribuída. De acordo
com a análise, a empresa XYZ não possui uma infra-estrutura de comunicações,
suficiente para atender a todos os seus projetos. Uma vez que a comunicação é um
fator crítico para o sucesso de projetos de DDS, a alta gerência da empresa XYZ
deveria se atentar para as limitações tecnológicas de suas unidades de
desenvolvimento. Em todo caso, os gestores dos projetos precisam atentar para as
limitações técnicas no planejamento das comunicações, programando-se para
agendar as reuniões e salas de videoconferência com antecedência, respeitando
também as limitações dos demais stakeholders.

Na análise crítica, foi relatado que o departamento de produtos da empresa,

um dos stakeholders do projeto, só passou a se envolver tardiamente, ocasionando
retrabalho em alguns módulos do programa. Por causa disso, pode-se constatar que
a identificação e o mapeamento dos interesses dos stakeholders são práticas que
precisam ser feitas com alguma frequência no desenvolvimento do projeto
 79

(normalmente, na empresa XYZ, este processo só é executado no início do projeto,

quando isto ocorre).

Outra dificuldade apresentada na análise crítica foi no gerenciamento de

expectativas de stakeholders, devido à distância geográfica e à utilização de meios
de comunicação limitados, como e-mails e ferramentas de mensagens instantâneas.
Neste caso, a comunicação frequente por telefone ou videoconferência pode ser
mais eficiente. Outra sugestão baseada em uma das recomendações de Junior et al
(2008) consiste na liberação periódica de produtos de trabalho, como artefatos de
especificação e versões preliminares do software. Assim, o cliente poderia
acompanhar o trabalho da equipe, opinando e solicitando correções
antecipadamente, no caso de alguma eventual incompreensão no levantamento de
requisitos.

Também foi relatada a falta de conhecimento sobre o escopo e as atividades

dos demais projetos do programa. A partir disto, podemos presumir que a
comunicação entre as equipes dos projetos distribuídos é bastante deficiente. Uma
boa recomendação acerca da distribuição de informações em projetos de DDS é a
criação de uma base de conhecimento on-line, que possa ser acessada a qualquer
momento e de qualquer local. Muitas falhas de comunicação podem ser evitadas
quando são divulgadas informações acerca do projeto e de suas atividades.

Em projetos de DDS, Audy e Prikladinicki (2007) afirmam que o

gerenciamento de riscos deve ocorrer em nível de projeto, mas principalmente em
nível organizacional, no sentido de se analisar as vantagens de se desenvolver um
projeto de forma distribuída e, caso seja, quais os riscos envolvidos. Os autores
afirmam que o gestor do projeto deve ter ciência dos riscos identificados no
momento em que se optou pelo desenvolvimento distribuído. Isto não ocorreu no
programa ALFA; a identificação dos riscos tem sido feita de forma isolada, por cada
equipe de projeto. De acordo com a pesquisa, os gestores de projeto afirmam que os
stakeholders não são adequadamente orientados em relação aos riscos do projeto.
Isto é um problema, pois alguns riscos podem ser eliminados ou mitigados com o
apoio destes stakeholders.

A pesquisa denota um baixo percentual de projetos concluídos dentro do

prazo, por parte dos gestores entrevistados. De fato, Wirick (2009) explica que
atrasos são muito comuns em projetos do setor público. Na análise crítica do
 80

programa ALFA, por exemplo, observou-se que existe dificuldade no

sequenciamento das tarefas do projeto. Uma vez que o desenvolvimento está
distribuído, existem muitas dependências. Uma boa prática no processo de definição
de escopo seria tentar mapear as dependências entre projetos antecipadamente e
documentá-las como premissas, caracterizando, de certa forma, uma garantia para a
equipe do projeto. Atualmente, devido à ausência de uma base de conhecimento, há
muita dificuldade em se enumerar atividades e planejar sua duração; tampouco
existe a consulta a especialistas, conforme a pesquisa evidencia. Isto prejudica o
processo de estimativa de duração das atividades. Outra dificuldade referente ao
tempo, levantada em nossa análise, diz respeito à falta de um calendário com datas
importantes, como viagens e reuniões. Eu acrescentaria a este calendário outras
datas como feriados (nacionais e regionais) e ausências programadas dos
stakeholders (férias e licenças, por exemplo). Por sinal, esta é uma das
recomendações de Siqueira e Silva (2006) para o planejamento de cronogramas em
projetos de DDS.

A pesquisa apontou que o apoio por parte do escritório de projetos da

empresa XYZ é deficiente, na visão de alguns dos entrevistados. Por sua vez, a
análise crítica denota que o gestor dos projetos costuma gerar relatórios de
desempenho (em alguns casos, mais de uma vez, por negligência na obtenção das
informações por parte dos interessados), reportando o andamento, os riscos e os
problemas do projeto. Como exemplo da falta de apoio do escritório de projetos,
podemos citar um dos problemas ilustrados pela pesquisa: em projetos da empresa
XYZ, geralmente a declaração de escopo é assinada tardiamente. O
desenvolvimento do software normalmente inicia antes desta formalização, de forma
a evitar os atrasos ocasionados pela espera; isto, definitivamente, não é uma boa
prática. Se o projeto é essencial para o alcance das metas estratégicas da empresa
XYZ, o escritório de projetos deveria intervir para que a formalização do projeto
ocorra de forma breve e tranquila, evitando retrabalho que não será contabilizado no
cronograma do projeto. Entretanto, talvez seja precipitado concluir que o escritório
de projetos da empresa XYZ ignora os dados informados pelos gestores e não os
apóia de nenhuma forma. A burocratização e a política, presenças constantes em
organizações públicas, não permitem determinadas ações, o que pode contribuir
para o índice baixo na pesquisa sobre a atuação do escritório de projetos.
 81

O processo de desenvolvimento de software utilizado no programa ALFA é

baseado no processo institucional da empresa XYZ. Uma grande dificuldade
apontada no programa é na padronização de artefatos e dos processos, o que é
uma boa prática neste tipo de desenvolvimento. Os problemas se devem, em sua
maior parte, às diferentes culturas de desenvolvimento de software em cada unidade
da empresa XYZ. Como foi observado por Siqueira e Silva (2006), em projetos de
DDS, as diferenças de percepção de não-conformidades podem ser distintas entre
as equipes de qualidade, o que realmente ocorre nos projetos da empresa XYZ. É
possível, entretanto, encontrar diferenças muito grandes em artefatos de diferentes
projetos de uma mesma unidade, pois não existe auditoria na qualidade do produto.
As auditorias das equipes de qualidade da empresa XYZ, até agora, só analisam a
aderência ao processo. Portanto, pode-se concluir que esta dificuldade tem raízes
institucionais, demandando intervenções por parte da alta gerência da empresa.

O gerenciamento de mudanças em ambientes distribuídos tende a ser

extremamente complexo, mas nossa análise demonstrou que atualmente existe um
processo de gerenciamento de mudanças bem definido para o programa ALFA. A
existência do processo não significa, porém, que não ocorrem problemas
relacionados a esta área. Por falta de disseminação do processo, os stakeholders e
a própria equipe do projeto eventualmente tem problemas em solicitar / receber
propostas de mudança. Apesar de supostamente bem definido, o processo de
gerenciamento de mudanças não está amadurecido o suficiente na empresa XYZ: a
pesquisa apontou deficiência na análise de mudanças por um comitê específico para
tal. Com base nisto, podemos concluir que, normalmente, não existe uma análise
cuidadosa das mudanças solicitadas em projetos da empresa XYZ.

Normalmente, os projetos desenvolvidos na empresa XYZ não têm seus

custos gerenciados, inclusive no programa ALFA. Isto não é algo surpreendente,
visto que a empresa XYZ é do setor público. Porém, de acordo com Wirick (2009), o
conhecimento das informações referentes ao custo permite um maior embasamento
no processo de tomada de decisões. Além disso, através das informações de custo
de um projeto, é possível avaliar a performance do mesmo. Há uma grande
tendência a gastos com viagens e telecomunicações em projetos de DDS; estes
gastos normalmente são controlados por departamentos específicos em
organizações do setor público. Recentemente, o escritório de projetos da empresa
 82

manifestou a intenção de promover a gerência de custos nos projetos, com o apoio

da ferramenta de gestão de projetos recém-implantada Clarity. Isto mostra que o
escritório de projetos visa amadurecer o processo de desenvolvimento de software
da empresa.

Pelo fato de pertencer ao setor público, a empresa XYZ possui problemas

característicos relativos a recursos humanos. Por exemplo, os projetos são
compostos por funcionários da empresa, geralmente selecionados quanto a sua
disponibilidade. Uma informação interessante acerca do programa ALFA é que a
grande maioria dos membros das equipes dos projetos foi alocada quase que
imediatamente após o seu ingresso na empresa. É notável a falta de experiência de
alguns funcionários, assim como a distribuição desequilibrada de talentos em
algumas equipes. O gestor do projeto precisa estar ciente destas limitações e
negociar com o gestor dos recursos humanos de forma a obter pessoas que sejam
capazes de contribuir com o projeto, mesmo que necessitem de treinamento prévio.

Em se falando de treinamentos, como em qualquer organização do setor

público, a restrição orçamentária é um fator que prejudica a realização dos mesmos.
Para amenizar a carência de treinamentos com especialistas, a empresa XYZ tenta
promovê-los com talentos da própria empresa, sujeitos à formação de turmas. Na
análise crítica, observou-se que não há como o gestor programar os treinamentos
necessários para sua equipe antecipadamente, uma vez que, quando ocorrem, é
porque há disponibilidade financeira e uma demanda considerável. A pesquisa
também evidenciou uma carência em treinamentos específicos para gestão por parte
dos gestores.

Ainda sobre os recursos humanos na empresa XYZ, a cultura organizacional

do setor público ainda é um empecilho para o gerenciamento de projetos. Embora a
empresa seja caracterizada como matricial fraca, algumas áreas da empresa ainda
atuam de forma funcional. Além disso, a empresa não possui um sistema de
promoções por desempenho em projetos, nem formas de reconhecimento individual,
causando desmotivação nos membros dos projetos. Infelizmente, as ações para
melhoria do cenário de recursos humanos da empresa XYZ não dependem de boas
práticas em gerenciamento de projetos; esta situação está condicionada às
prioridades da alta gerência da empresa, baseada em seu planejamento estratégico.
 83

A disseminação do conhecimento é uma prática que está ainda sendo

cultivada na empresa XYZ. A pesquisa aponta dois pontos bastante conflitantes:
enquanto praticamente todos registram as lições aprendidas de seus projetos,
poucos consultam estas informações no planejamento de seus projetos. A empresa
XYZ está começando a utilizar a ferramenta de gestão de projetos Clarity como
SIGP. Por meio da base de conhecimento provida pela ferramenta, será mais fácil e
prático consultar as informações de projetos anteriores, assim como as lições
aprendidas dos projetos. Uma boa prática, sobretudo em projetos de DDS, é
consultar a base de conhecimento de projetos de uma organização na fase de
planejamento. Neste sentido, atualmente, a empresa XYZ possui um portal com
blogs mantidos por funcionários, onde podem ser encontradas informações
institucionais, informações acerca do programa ALFA, tutoriais e dicas para
documentação e implementação de software. Esta excelente iniciativa não partiu da
alta gerência da empresa, embora a mesma simpatize com a ideia. Mas, devido a
prioridades estratégicas e falta de apoio e divulgação, esta ferramenta útil é
subutilizada.

A empresa XYZ ainda está aprimorando seus processos para se adequar aos
projetos de DDS. Por falta de experiência prévia neste tipo de desenvolvimento, é
normal que o programa ALFA apresente problemas em sua execução. Se seguidas
corretamente, as boas práticas do PMBOK podem diminuir a incidência de
problemas principalmente na área de comunicação, que é essencial para os projetos
de DDS, como o programa ALFA. Entretanto, como pudemos observar, alguns dos
problemas apresentados, como problemas na área de recursos humanos e na área
de qualidade, precisam de apoio da alta gerência.
 84

6.2 Conclusões individuais de Aline Lima Viana

Como foi mostrada, a crescente aceitação do gerenciamento de projetos

indica que a aplicação de conhecimentos, processos, habilidades, ferramentas e
técnicas adequadas, podem ter um impacto significativo no sucesso de um projeto.

Neste contexto, foi destacada também a importância do PMI (Project

Management Institute), organização líder em gerenciamento de projetos em todo o
mundo, cujo principal compromisso é “promover o profissionalismo e a ética em
gestão de projetos”, e que possui como uma de suas grandes contribuições na
divulgação das boas práticas de gerenciamento de projetos, a publicação de um
documento denominado “A Guide to the Project Management Body of Knowledge
(PMBOK®)”.

Explanamos sobre a aplicabilidade desse conjunto de boas práticas dentro

das várias áreas de conhecimento relacionadas ao gerenciamento de projetos.

Abordamos aspectos relacionados ao gerenciamento de projetos em

empresas públicas, bem como ao desenvolvimento distribuído de software.

Por fim, realizamos um breve histórico sobre a empresa XYZ, alvo do

presente trabalho, bem como sobre o programa ALFA por ela desenvolvido.
Analisamos a problemática relacionada ao gerenciamento de projetos em uma
empresa pública, onde alguns de seus projetos de software são desenvolvidos de
forma distribuída. Relatamos diversas situações observadas como consequência da
experiência diária dos autores na referida empresa, bem como, coletamos dados
através de uma pesquisa, com o objetivo de obtermos informações sobre o grau de
maturidade da empresa no tocante ao gerenciamento de projetos e sobre nível de
capacitação dos seus gestores de projeto no programa ALFA.

No presente capítulo, relaciono algumas sugestões que visam contornar

várias das situações mencionadas no capítulo anterior. Com base na literatura e a
partir da minha análise pessoal acerca da situação retratada no estudo de caso,
seleciono as áreas de conhecimento que considero de maior relevância dentro do
contexto deste trabalho, são elas: Comunicação, Recursos Humanos, Qualidade,
Integração e Tempo. Em seguida, listo algumas recomendações baseadas nas boas
práticas de gerenciamento de projetos, relacionadas às áreas de conhecimento
 85

citadas. Vale ressaltar que as recomendações estão agrupadas de acordo com a

área a que se relaciona a ação recomendada, podendo tal ação repercutir em outras
áreas.

Carmel (1999), citado por Junior et al (2009), sugere a existência de cinco

fatores que podem levar uma equipe distribuída ao fracasso: comunicação
ineficiente, falta de coordenação, dispersão geográfica, perda do espírito de equipe
e diferenças culturais, chamadas de forças centrífugas.

A importância da comunicação também é ressaltada no PMI (2008), quando

menciona que uma comunicação eficaz cria uma ponte entre as diversas partes
interessadas envolvidas no projeto, conectando vários ambientes culturais e
organizacionais, diferentes níveis de conhecimento, e diversas perspectivas e
interesses na execução ou nos resultados do projeto. Partindo da relevância que
tem essa área no desenvolvimento distribuído de software, seguem alguns pontos a
serem observados relacionados ao gerenciamento da comunicação:

 Priorizar a realização das validações dos artefatos de forma presencial,

diminuindo as possíveis perdas no processo de comunicação devido à
distribuição geográfica, realizando uma checagem das informações recebidas
até o momento, onde foram utilizados outros mecanismos de comunicação.

 Divulgar junto aos stakeholders quanto ao uso efetivo dos mecanismos já

existentes de report do projeto, promovendo uma diminuição na geração de
informações redundantes e reduzindo a sobrecarga de atividades da equipe,
principalmente dos gestores.

 Realizar os processos de identificação das partes interessadas e de

planejamento da comunicação de cada projeto de maneira a mapear de forma
mais efetiva todos os stakeholders envolvidos e quais informações cada um
deverá receber, reduzindo o impacto da distribuição geográfica dos
envolvidos no programa, evitando assim o negligenciamento de stakeholders
e a perda de informações. Segundo o PMI (2008), o planejamento
inadequado das comunicações poderá causar problemas, tais como atraso na
entrega de mensagens, comunicação de informações confidenciais para o
público incorreto ou falta de comunicação para algumas das partes
interessadas necessárias.
 86

 Garantir através do plano de comunicação que as atas de reuniões dos

projetos sejam devidamente geradas, armazenadas e distribuídas, como
forma de registro e validação das decisões tomadas, atenuando possíveis
perdas na comunicação devido à distribuição geográfica.

 Planejar e escolher cuidadosamente as ferramentas que serão utilizadas na

comunicação, priorizando aquelas que gerem menos perdas neste processo,
pois uma vez que estamos tratando de projetos distribuídos, o cuidado para
minimizar as possíveis interferências deverá ser redobrado;

 Incentivar o acompanhamento da evolução dos pelos seus membros através

do SIGP, como forma de gerar motivação e reforçar uma visão de equipe
enquanto programa.

 Planejar a utilização das salas de videoconferência pelos projetos, de modo

que todos eles possam usufruir de forma igualitária dos benefícios
proporcionados pelas reuniões síncronas, tais como: diminuição das
distâncias entre os projetos do programa, entre os projetos e os clientes;
acesso às expressões faciais, inflexões de voz, linguagem corporal, entre
outros, como importantes ferramentas no processo de comunicação.

 Incluir os eventos e datas relativos a viagens do projeto e do programa no

plano de comunicação, fazendo com que as reuniões presenciais entre os
projetos e com os clientes possam contar com todos os participantes
necessários, possibilitando assim que as mesmas alcancem os resultados
esperados.

Ainda segundo Carmel (1999), citado por Junior et al (2009), é sugerida a

existência de seis fatores que podem levar a equipe ao sucesso: infraestrutura de
comunicação, arquitetura do produto, construção de uma equipe, metodologia de
desenvolvimento, tecnologia de colaboração e técnicas de gerência.

Partindo dos fatores de sucesso citados acima e ressaltando que a área de

qualidade tem como finalidade assegurar que o projeto atinja os objetivos para os
quais foi criado, utilizando processos para garantir, dentre outras coisas, que a
metodologia de desenvolvimento e as técnicas adotadas para tal fim estejam sendo
corretamente aplicadas, listo abaixo algumas sugestões relacionadas a esta área:
 87

 No processo de planejamento da qualidade, promover um alinhamento entre

as equipes distribuídas da qualidade com o objetivo de:

o Nivelar as orientações repassadas aos projetos acerca dos padrões de

qualidade, facilitando o entendimento dos artefatos produzidos e
eliminando a necessidade de retrabalho posterior na tentativa de
equalizá-los.

o Promover auditorias da qualidade que sigam critérios semelhantes

como uma forma de garantir que as orientações fornecidas sejam
seguidas por todos os projetos do programa e que os artefatos por eles
produzidos alcancem um mesmo patamar de qualidade.

 No processo de planejamento da qualidade, analisar a existência de

atividades ou documentações excessivas. Segundo Junior et al (2009), deve-
se manter o processo o mais simples possível, pois quanto mais complexo,
mais difícil será ter o controle sobre as atividades desenvolvidas pelos
componentes das equipes;

 Garantir que as equipes documentem adequadamente as alterações

realizadas nos artefatos dos projetos. Tal prática ganha mais relevância ainda
quando se trata de desenvolvimento distribuído de software, no qual um
artefato alterado por uma equipe necessitará ser compreendido por uma outra
equipe.

 Estruturar as equipes de qualidade de modo que as mesmas tenham

condições de realizar os processos de controle e garantia da qualidade do
produto, além da qualidade do processo. Tal medida visa assegurar que as
entregas produzidas atendam aos requisitos de qualidade estabelecidos e
reduzir custos. De acordo com o PMI (2008), o custo de prevenir os erros
geralmente é muito menor do que o custo de corrigi-los quando são
encontrados pela inspeção.

Segundo o PMI (2008), no contexto de gerenciamento de projetos, integração

inclui características de unificação, consolidação, articulação e ações integradoras
que são essenciais para o término do projeto, para gerenciar com sucesso as
 88

expectativas das partes interessadas e atender aos requisitos. O gerenciamento da

integração do projeto requer que sejam feitas escolhas sobre alocação de recursos,
concessões entre objetivos e alternativas conflitantes e gerenciamento de
dependências mútuas entre as áreas de conhecimento. Devido ao fato da área de
integração conter processos cruciais para a obtenção de bons resultados no
gerenciamento de projetos, e que a execução de tais processos se torna ainda mais
complexa quando o contexto se refere a programas distribuídos, destaco abaixo
algumas sugestões de boas práticas relacionadas a esta área:

 Fazer uso das lições aprendidas registradas pelos projetos anteriores durante
o desenvolvimento do plano de gerenciamento dos novos projetos do
programa e definição de métricas e indicadores adequados para acompanhar
a evolução do trabalho.

 Maximizar a utilização do SIGP adotado pela empresa, para que o mesmo

possa apoiar o processo de orientação e gerenciamento da execução do
projeto.

 Incentivar a adoção de um comitê de controle de mudanças para atuar na

revisão das solicitações de mudança e aprovação ou rejeição das mesmas,
propiciando que o controle integrado de mudanças seja realizado de forma
mais segura e controlada.

 Promover uma maior integração entre o departamento de produtos e o cliente

de forma que o processo de controle integrado de mudanças estabelecido
para a empresa possa ser efetivamente seguido, permitindo que o projeto
possa ser controlado de forma satisfatória.

 Tornar uma prática usual atividades como acompanhamento constante do

trabalho realizado, utilização mais efetiva de métricas para facilitar o controle,
avaliação do desempenho para identificar possíveis necessidades de ações
corretivas ou preventivas, monitoramento da execução das mudanças
aprovadas. Tais ações visam minimizar os atrasos nas atividades dos
projetos, intensificados pela existência de dependências entre os mesmos.

 Adotar a prática de atualização do plano de gerenciamento, pois apesar da

pesquisa haver constatado um bom percentual de projetos em conformidade
com este quesito, também demonstra que o mesmo ainda não é aplicado pela
 89

totalidade do programa. Esta prática visa dar credibilidade às informações

fornecidas aos stakeholders e respaldar as ações tomadas no nível de
gerenciamento do programa.

Dinsmore e Silveira Neto (2005), citados por Souza e Ferreira (2006), afirmam
que quando se trata de planejamento, muitos pensam logo em ferramentas
automatizadas (software) de controle de projetos. É inegável que sua rapidez e
confiabilidade facilitam a vida do gerente de projetos, e projetos de médio e de
grande porte não dispensam seu uso. Mas enfatizar demais este aspecto sem levar
em conta as pessoas da equipe e o comportamento humano das mesmas pode
prejudicar ou pôr a perder todo o esforço tecnológico empregado no projeto.

Em entrevista exclusiva à revista MundoPM, de junho de 2005, Kerzner, citado

por Souza e Ferreira (2006), afirma que antigamente a culpa de todas as falhas em
projetos era atribuída à falta de planejamento e à falta de controle de prazos e de
custos. Hoje o autor acredita que a maioria das falhas é resultante de fatores
comportamentais. Portanto, podemos perceber o quanto o componente humano e
fatores como capacitação técnica e comportamental, habilidades interpessoais e
trabalho em equipe são decisivos para o sucesso de um projeto. Abaixo menciono
algumas recomendações referentes a esta área:

 Preparar as equipes com relação às práticas de gerenciamento de projetos

com o objetivo de promover um melhor desempenho dos atuais gestores,
viabilizar o aproveitamento de outros recursos na execução de tais atividades
de forma adequada e permitir que possam ser identificadas mais facilmente
as pessoas com perfil para essa atividade.

 Promover constantes treinamentos sobre gerenciamento da qualidade,

disseminando a importância das práticas desta área, melhorando a qualidade
dos artefatos produzidos e consequentemente facilitando o trabalho da área
responsável pela qualidade dos projetos do programa.

 Criar um pool de recursos, onde os integrantes sejam treinados em funções

onde os projetos mais estejam necessitando ou onde o recurso se ache
deficiente, evitando que os projetos que se encontrem em fase final tenham
que lidar com uma superalocação pela impossibilidade de liberação imediata
de alguns recursos e permitindo que os projetos que estejam necessitando de
 90

novos recursos possam obtê-los mais prontamente, evitando atrasos

desnecessários.

 Realizar periodicamente eventos e treinamentos com enfoque comporta

mental, com o objetivo de reforçar o senso de equipe enquanto programa,
facilitando a colaboração entre as equipes e diminuindo a ocorrência de
conflitos interpessoais.

 Realizar constantes reuniões no âmbito dos projetos para nivelar o

conhecimento e definir os papéis de cada membro da equipe, devido à
heterogeneidade de conhecimento e de perfis. Tais medidas visam evitar
problemas gerados pela compreensão diferenciada a respeito do escopo, das
metas do projeto e do trabalho a ser realizado;

 Treinar a equipe no processo da fábrica, pois é de suma importância que

todos tenham pleno conhecimento de todo o funcionamento do processo em
que estão inseridos;

Na situação analisada, detectei que muitos dos problemas ocorridos em

outras áreas, como falhas do processo de comunicação devido em grande parte à
distribuição geográfica, falta de cooperação entre as equipes resultando em
morosidade, controle insuficiente da qualidade das entregas produzidas gerando
retrabalho, acabam gerando graves consequências no controle dos prazos dos
projetos. Portanto, entendo que para minorar o impacto decorrente das demais
áreas, é de suma importância que o planejamento e o controle do cronograma
considerem certos fatores, como mencionado abaixo:

 Realizar o processo de desenvolvimento do cronograma em sincronismo com

os demais projetos com o objetivo de:

o Maximizar o aproveitamento do tempo dos clientes compartilhados por

mais de um projeto, minimizando atrasos nas tarefas do projeto que
dependam da participação do cliente.

o Estabelecer previamente as reuniões em comum para que haja o

devido planejamento das pautas, evitando assim um número excessivo
de reuniões que acabam por retardar o andamento das atividades
rotineiras dos projetos.
 91

 Desenvolver o cronograma do projeto levando em conta:

o O planejamento dos treinamentos necessários a fim de que o tempo

utilizado para a sua realização não venha a ser convertido como atraso
no projeto.

o O plano de gerenciamento de riscos, através da utilização, por

exemplo, de reservas de contingência para contornar situações aonde
um ou mais riscos venham a se concretizar.

o As viagens do projeto a serem realizadas, fazendo com que as

respectivas tarefas de preparação para as viagens, uma vez tendo sido
previamente planejadas, não se convertam em atrasos para o projeto.

 Criar uma base de conhecimento com informações dos projetos e utilizar as

informações já disponibilizadas, como as lições aprendidas dos projetos
finalizados, com o objetivo de que tais dados forneçam um embasamento
para os novos projetos do programa, como por exemplo, proporcionar uma
estimativa mais precisa de duração das atividades.

 Promover uma maior interação com o cliente durante os processos de coleta

de requisitos e definição do escopo, na tentativa de consolidar ao máximo os
requisitos e as entregas a serem produzidas, diminuindo o retrabalho e assim
minimizando a quebra dos prazos.
 92

6.3 Conclusões individuais de Lucinaldo Araújo Maciel

O gerenciamento de projetos vem se consolidando cada vez mais com uma

forma eficaz de aumentar os índices de sucesso em projetos.

Durante este estudo, foram investigadas as práticas de gerenciamento de

projeto que poderiam influenciar positivamente no sucesso dos projetos de
desenvolvimento empreendidos pela empresa XYZ.

Inicialmente serão apresentadas as razões que levaram o gerenciamento de

projetos a alcançar a importância que hoje o mesmo tem na vida das empresas. Em
seguida serão apresentadas sugestões de como a empresa XYZ poderá usar as
boas práticas em gerenciamento de projetos para melhorar o resultado apresentados
pelos projetos desenvolvidos nesta empresa.

Há alguns anos os produtos e serviços oferecidos aos consumidores eram

trabalhados em ciclos longos, com uma forte fidelização dos clientes e em um
processo de renovação que permitia que as empresas desenvolvessem os novos
produtos através de processos relativamente simples e demorados. Poderíamos
citar vários produtos que foram líderes de segmento durante décadas sem que
houvesse uma grande pressão competitiva sobre eles.

Este cenário predominou até os meados da era industrial, onde o mais

importante era a posse dos bens de produção e o diferencial competitivo era
principalmente a qualidade do produto. O foco era o produto, suas características e
seu processo de fabricação. Nesta fase os bens de consumo eram “feitos para
durar” e as preferências eram comumente passadas de geração em geração.

Hoje este cenário é impensável. A televisão e mais recentemente a internet

mudaram completamente a forma como as pessoas encaram os produtos, os
serviços e principalmente o processo de consumo. O ciclo dos produtos está cada
vez mais curto e o número de competidores por segmento está cada vez maior.

Para sustentar esta forma produtiva, os produtos agora têm “prazo de

validade” curto. Vejamos o exemplo dos celulares, que ficam obsoletos e são
trocados muito rapidamente, mesmo mantendo suas características funcionais e
operacionais inalteradas. O celular que era “top de linha” no ano passado não tem
 93

aquela nova função que é a “onda” do mercado hoje e que muitos consumidores
desejam.

Estamos atualmente na era da informação. O processo fabril é apenas parte

de uma cadeia produtiva que em muitos casos é terceirizado em uma ou mais
fábricas, pois agora o que vale mais não é o produto em si ou sua fabricação, mas
as informações e “sentimentos” que estão associados a ele. Em outras palavras,
com o desenvolvimento da tecnologia e dos processos produtivos, o mais importante
atualmente é deter e tratar as informações necessárias para transformar as ideias e
conceitos em negócios e lucros para as empresas.

Dentro desta realidade trazida pela era da informação, os projetos são

comprovadamente o caminho mais eficaz para transformar o planejamento
estratégico da empresa em negócios capazes de impulsioná-la aos patamares
planejados, viabilizando sua sobrevivência.

Os projetos surgiram como uma maneira de organizar as ações e os recursos

necessários para a viabilização das mudanças. Com o tempo este caminho se
mostrou promissor e os projetos se tornaram cada vez mais complexos e difíceis de
gerenciar.

O aumento da complexidade dos projetos impulsionou o interesse pela

melhoria do gerenciamento de projetos e a necessidade de estudos nas áreas de
conhecimento relacionadas ao tema. Como uma característica intrínseca de um
projeto é a geração de produtos, serviços ou resultados únicos, tornava-se difícil
compará-los ou tentar repeti-los na busca da obtenção de resultados semelhantes.
Passou-se então a se analisar que práticas de gerenciamento eram utilizadas nos
projetos que atingiam seus objetivos, para poder usar estas mesmas práticas nos
projetos seguintes.

Surgiram então várias compilações de boas práticas de projeto. Dentre elas

uma das mais conhecidas e utilizadas é o PMBOK, guia elaborado e mantido pelo
PMI. Este guia consolida as informações de gerenciamento de projetos no mundo
todo e classifica estas informações em 9 áreas de conhecimento, com os processos
divididos em 5 categorias de grupos de processo.

Pelo explanado até aqui, foi possível determinar a motivação para que o
gerenciamento de projeto seja realizado com o maior grau de seriedade e
 94

profissionalismo possível. Deste ponto em diante o objetivo é destacar os fatores

mais importantes e críticos no gerenciamento de projetos e de programas de porte
semelhante do programa ALFA, empreendido pela empresa XYZ.

O gerenciamento de projetos em geral já tem seus desafios: riscos não

detectados, problemas de comunicação, questões ligadas aos recursos humanos,
problemas com fornecedores, prazos mal estimados, enfim, uma série de questões
que interferem no andamento dos projetos. No gerenciamento de programas estes
problemas são sensivelmente multiplicados, uma vez que além dos problemas
individuais dos projetos temos os problemas provocados pela integração e
interdependência entre os projetos.

A empresa XYZ já tem bastante experiência e maturidade no gerenciamento

de projetos individuais, mas o gerenciamento de programas e de portfólio ainda é
uma atividade em amadurecimento. A empresa usa um sistema integrado de
gerenciamento de projetos (SIGP), mas como ainda não tem grande experiência
neste uso, principalmente no gerenciamento de programas e portfólios, ainda não
consegue colher todos os frutos que a ferramenta pode oferecer.

Os projetos da empresa XYZ têm um desafio adicional que se soma aos

tantos outros que um gerente de projeto tem que enfrentar normalmente: o tamanho
dos seus projetos. Os sistemas desenvolvidos pela empresa têm em geral um
número expressivo de funcionalidades, um grande número de usuários e manipula
largos volumes de dados. Esta característica faz com que a construção e a
manutenção desses sistemas sejam bastante complexas. O efeito desta
característica é que o desenvolvimento destes sistemas tem que ser dividido e
organizado em vários projetos para que o tempo de desenvolvimento seja viável. Em
alguns casos não é possível criar todos os projetos na mesma unidade de
desenvolvimento, pois cada unidade já tem vários projetos iniciados e não suporta a
criação de muitos projetos novos.

Este foi o caso do programa ALFA, que tem um total de 19 projetos e que
desenvolve um sistema que será usado nacionalmente por mais de 2.500 usuários
da empresa cliente, sem contar os usuários da população em geral que farão acesso
ao sistema via internet. No seu processo de desenvolvimento, existem projetos
sediados nas unidades de desenvolvimento do Ceará, do Rio de Janeiro e de Santa
Catarina. O programa contém um projeto que é responsável pela gestão do negócio
 95

e pelas decisões comuns ao programa, respondendo também pela comunicação

com o cliente gestor para definição das diretrizes e padrões a serem utilizados no
sistema. Outro projeto com características especiais é o que faz a integração técnica
do código produzido pelos demais projetos, uma vez que todo o código gerado
compõe um único portal, sendo para o cliente um sistema único.

Além de todas as dificuldades do programa ALFA, já listadas acima, temos

mais algumas relacionadas ao cliente.

A primeira delas é que o cliente se encontra em um local físico diferente de

todas as unidades de desenvolvimento participantes do programa. Enquanto as
equipes dos projetos estão no Ceará, no Rio de Janeiro e em Brasília, o cliente se
concentra em Brasília, sede administrativa da sua empresa. Um problema
complementar a este é que as equipes do cliente são compostas por pessoas de
outros Estados que foram convocadas para trabalhar em Brasília durante o período
de desenvolvimento e homologação do sistema. Por conta disso, periodicamente
estas pessoas voltam para suas bases operacionais e ficam indisponíveis para o
projeto.

Em relação aos fornecedores de requisitos do cliente, acontece que nem

sempre eles têm o mesmo entendimento em relação às regras de negócio a serem
desenvolvidas. Quando há uma divergência e nenhuma das partes quer ceder, um
comitê é organizado para tratar do assunto e isto torna o processo lento,
desgastante e oneroso.

Percebemos que o cliente não participa efetivamente de todas as decisões

importantes para o programa ALFA e isto acaba gerando retrabalhos quando o
mesmo discorda das soluções aplicadas. Acredito que alguns fatores contribuam
para que isto ocorra. O primeiro é o distanciamento físico já mencionado acima, o
que dificulta o processo de comunicação. O segundo é que o cliente tem
representantes de vários níveis hierárquicos e de conhecimento técnico e em alguns
momentos existe discordância entre estes representantes e o responsável pela
decisão não tem autoridade suficiente para sustentá-la perante os escalões
hierárquicos mais altos. O terceiro é a falta de participação dos especialistas de TIC
do cliente nos processo de acompanhamento dos projetos. A sugestão é que o
mesmo acompanhamento de negócios que é feito mensalmente através de uma
 96

reunião executiva entre empresa XYZ e seus clientes, também seja realizado em
nível técnico, envolvendo o projeto gestor e a coordenação de TIC do cliente.

Também em relação aos clientes, uma ação positiva que poderia ser buscada
pela empresa XYZ seria o aumento do número de pessoas envolvidas na definição
dos requisitos e regras de negócio do programa ALFA. Como em vários projetos só
existe um representante do cliente, esta pessoa acaba não dominando todo o
negócio ou tendo dúvidas em alguns pontos. Esta pessoa estando sozinha, não tem
com quem debater e sente dificuldades para chegar à melhor definição das regras
envolvidas. Como o problema é no cliente, a atuação da empresa neste caso seria
fazer uma sensibilização do mesmo mostrando os benefícios que um aumento do
efetivo traria para os projetos e consequentemente para o programa ALFA.

Um desafio que envolve tanto a equipe da empresa XYZ quanto o próprio

cliente é a superação das diferenças regionais e culturais dos stakeholders. Entre
desenvolvedores e clientes, o programa ALFA tem representantes de praticamente
todos os Estados brasileiros, cada um com uma formação cultural e técnica
diferente. Unir todo este grupo e fazer com que todos trabalhem alinhados para o
desenvolvimento dos projetos é uma tarefa tão complexa que cada gestor de
projeto, cada membro de equipe e cada representante do cliente que se tornar um
agente de integração, muitas vezes abrindo mão das suas preferências para aceitar
as decisões que melhor contribuam para o bom andamento do programa ALFA.

Além da questão de integração dentro do programa, existem várias outras

integrações do sistema que está sendo desenvolvido com os demais sistemas já
existentes no cliente. O sistema resultante do programa ALFA deverá se comunicar
com alguns sistemas que já se encontram em produção ou que também estão sendo
desenvolvidos. Em relação aos sistemas que já estão em produção, um complicador
é que vários deles foram desenvolvidos em linguagens mais antigas e sem um
mecanismo de comunicação muito eficiente. Alguns estão funcionando em
plataforma Alta (Mainframe) e só permitem comunicação através de troca de
arquivos por protocolo FTP. Outros, mesmo em plataforma baixa apresentam
limitações de comunicação, tendo também que usar mecanismos de troca de
arquivos.

Tanto os sistemas em produção quanto os que ainda estão em

desenvolvimento passam por manutenções frequentes. Estas manutenções alteram
 97

elementos que acabam repercutindo na comunicação externa e gerando retrabalho

para os desenvolvedores do programa ALFA. Uma dificuldade adicional nesta
integração é que eles têm pouca ou nenhuma documentação formal sobre as regras
de negócio envolvidas e muito raramente possuem algum diagrama UML que retrate
como o sistema funciona. Isto faz com que mudanças solicitadas nestes sistemas ou
mesmo a solicitação de orientações para integração, tenham retornos demorados e
pouco precisos. Por várias vezes os responsáveis técnicos pelos sistemas tem que
“varrer” o código para fornecer as respostas solicitadas. Como as equipes de
manutenção geralmente têm poucos analistas, solicitações de informações ou
ajustes geram um esforço extra e não são bem recebidas por estas equipes.

Tanto a empresa XYZ quanto seus clientes são empresas públicas. Isto afeta
praticamente todas as áreas do gerenciamento de projeto na empresa e em
particular afeta bastante o programa ALFA.

Atualmente as empresas públicas têm procurado seguir as mesmas práticas

administrativas e de gerenciamento já adotadas pelas empresas privadas e que
propiciam uma forma de trabalho mais eficiente. Apesar deste esforço, uma serie de
limitações são impostas às empresas públicas que não permitem que estas evoluam
na mesma velocidade das empresas privadas.

O processo de contratação dos funcionários de uma empresa pública tem que

ser realizado por meio de concurso público. Este processo leva vários meses e não
permite que a composição ou recomposição das equipes ocorra tempestivamente.
Não é possível também selecionar os concursados de acordo com os perfis
desejados. A empresa deve seguir a sequência da classificação e só pode chamar
novos funcionários se houver disponibilidade de vagas no quadro autorizado pelo
órgão de planejamento da Administração Federal.

Ainda relacionado a esta característica das empresas envolvidas, temos que

conviver com as influências políticas na determinação de prazos e de estratégias de
desenvolvimento. Estes elementos muitas vezes se alteram com a mudança das
pessoas nos cargos estratégicos. Um ano eleitoral, bem como o primeiro ano de
mandato de um novo governo podem gerar atrasos no desenvolvimento dos
sistemas por conta de restrições orçamentárias ou da substituição de presidentes e
diretores, sejam estes das empresas que desenvolvem o projeto ou das empresas
 98

dos clientes. Alguns projetos chegam a ser cancelados quando perdem seu
stakeholder principal após mudanças nos quadros gerencial de sua organização.

Outra questão que penaliza os projetos da empresa XYZ é o processo de

aquisição de bens e serviços, que deve respeitar as imposições legais da lei de
licitações (8.666/93). As licitações são processos formais complexos e por isto o
tempo entre o projeto básico e a adjudicação do processo licitatório normalmente é
bastante longo.

Por conta de todos estes elementos que dificultam o bom andamento dos
projetos, a empresa XYZ tem investido cada vez mais em ferramentas e na gestão
de projetos. Ela possui um escritório de projetos (PMO) cuja maioria dos membros é
PMP e que auxilia os gestores na condução dos projetos. O que às vezes falta aos
componentes deste PMO é mais experiência em gerenciamento de projetos. Muitos
deles ainda são muito teóricos ou são de uma época em que a empresa não tinha
uma metodologia de gerenciamento de projetos bem definida. A certificação PMP é
importante, pois indica um estudo das boas práticas de gerenciamento, mas o ideal
é que isto seja complementado com alguns anos de prática em uma metodologia de
gerenciamento de projetos. O escritório de projetos tem que saber como as coisas
funcionam no dia a dia e entender as dificuldades que os gestores enfrentam para
conseguir manter a linha de base do projeto. Sem estas compreensões, a atuação
dos membros do escritório de projetos estará prejudicada.

A sugestão a seguir não é um consenso de mercado, mas acredito que na

empresa XYZ ela é necessária justamente para que as pessoas do PMO adquiram
mais experiência. A sugestão é que os membros atuais do PMO passem por um
período de reciclagem. Neste período eles passariam a atuar como gestores de
projeto sob a orientação de outro colega do PMO que seja mais experiente.

O PMO também deveria adotar um critério de seleção mais rigoroso, onde

fosse exigida a participação em pelo menos 3 projetos da empresa e um tempo de
atuação de 3 a 5 anos na área de gerência de projeto, para que um analista fosse
candidato a membro do escritório de projetos. Acredito que assim teríamos pessoas
experientes e sensíveis ao funcionamento da atividade de gerência de projetos na
empresa. Desta forma os gestores de projeto teriam um acompanhamento mais
eficaz.
 99

Outra sugestão diz respeito ao projeto ALFA-GESTOR, que gerencia o

programa ALFA. Atualmente ele tem uma atuação limitada no que diz respeito à
integração entre os projetos. Os dois principais objetivos para a criação deste projeto
foram promover a integração de negócio e promover a correta integração entre os
planejamentos dos projetos de forma que as dependências entre eles sejam tratadas
de modo que um projeto não provoque atrasos no planejamento dos demais. Esta
atividade chegou a ser realizada em parte, mas com o passar do tempo, a eficácia
da atuação do projeto foi diminuindo e culminou com a suspensão temporária do
mesmo. Recentemente a empresa reabriu o projeto e pudemos perceber um início
da retomada dos objetivos iniciais. Espero que esta tendência se efetive e sugiro
que o projeto seja fortalecido nestes dois aspectos para que todo o programa ganhe.

Um dos objetivos do projeto gestor que nunca foi efetivamente alcançado e

que sugerimos que seja buscado nesta nova fase é garantir que todos os demais
projetos do programa continuem alinhados não só com os objetivos do programa,
mas também com os objetivos estratégicos da empresa. Como gestor de um dos
projetos do programa ALFA, em poucas oportunidades ouvi alguma referência ao
planejamento estratégico da empresa e acredito que não havia uma revisão
sistemática dos objetivos e do escopo dos projetos de forma a buscar um
alinhamento em relação ao planejamento da empresa.

Na atual conjuntura de trabalho da empresa temos várias dificuldades para

colocar os sistemas em produção. Uma sugestão que pretende melhorar este
aspecto é que para cada projeto de desenvolvimento tenha um projeto
correspondente de infra-estrutura, e que estes dois projetos caminhem de forma
sincronizada. Em várias oportunidades sistemas já homologados pelo cliente não
puderam entrar em produção por não haver uma infra-estrutura de servidores e rede
adequados ao porte do sistema. As aquisições na empresa XYZ têm seguir o rito
imposto pela lei de licitações (8.666/93) e assim estes processos têm duração de
vários meses. Se estas aquisições fossem realizadas no escopo dos projetos de
infra-estrutura relacionados aos projetos de desenvolvimento, o próprio cronograma
sincronizado faria com que os ambientes estivessem prontos no tempo adequado e
não haveria prejuízo para o processo de desenvolvimento, nem para os clientes.
 100

Em um programa cujos projetos estão distribuídos geograficamente, um dos

fatores mais críticos é a comunicação. No programa ALFA pudemos constatar vários
problemas gerados por falhas na comunicação.

Um dos meios que utilizamos para minimizar estes riscos é o uso de reuniões
de videoconferência. Neste aspecto podem ser dadas duas sugestões: a primeira é
que, como em qualquer reunião, o número adequado de participantes é fator
decisivo para o sucesso ou fracasso da reunião. Em geral as videoconferências têm
mais participantes que o recomendado. Este número deveria ser redimensionado
para que as reuniões pudessem ser mais objetivas e que a participação de cada
analista fosse mais efetiva. Hoje o que se observa é que algumas pessoas
participam ativamente da videoconferência, outros estão dispersos e participam de
forma precária e um terceiro grupo quase não participa das conversas.

O número reduzido de salas de videoconferência é outro fator que atrapalha e

faz com que as reuniões tenham agendamento disponível em datas distantes,
inviabilizando a agilidade necessária aos projetos. O sugerido é que o número de
salas de videoconferência seja aumentado, para dar vazão à demanda que já existe
atualmente. Neste meio tempo a sugestão é que as videoconferências sejam
substituídas por audioconferências ou mesmo salas de discussão em sistemas de
mensagem instantânea (instant messenger). O importante é a agilidade e a
qualidade da comunicação entre os projetos e com o cliente.

A estabilidade dos requisitos e do escopo do projeto é um dos elementos

mais importantes para que as linhas de base de tempo e de custo do projeto possam
ser respeitadas. O programa ALFA precisa lidar melhor com esta questão. A
sugestão é a criação de um comitê de controle integrado de mudanças, composto
por representantes do cliente e da empresa XYZ e que contenha membros que
tenham conhecimento e autoridade para tomar as decisões em relação às
solicitações de mudanças colocadas em pauta. Com isto espera-se que as
alterações de escopo sejam reduzidas e que as que forem aprovadas possam gerar
uma nova linha de base para o projeto. Atualmente isto não acontece para boa parte
das mudanças solicitadas pelo cliente.

O programa ALFA tem atualmente problemas em relação à definição dos

padrões a serem adotados pelos projetos. Relacionado a isto temos outra questão
que é um complicador. A empresa XYZ recentemente trocou a tecnologia utilizada
 101

em seus projetos e ainda está passando por uma fase de indefinições e de

adaptação à nova tecnologia. Este ponto deve ser previamente resolvido pelo
departamento de arquitetura de software e o prazo para a apresentação desta
solução deve ser compatível com a urgência com que os projetos da empresa têm
em saber trabalhar com as novas ferramentas e tecnologias. Superada esta primeira
questão, projeto gestor e projeto integrador devem buscar a definição dos padrões
do programa ALFA para que os retrabalhos observados atualmente não voltem a
ocorrer no futuro.

Após a ocorrência de vários episódios de retrabalho por conta de falta de

padronização e da substituição do gestor do programa integrador, o programa ALFA
iniciou um trabalho de verificação de padrões e da definição dos que estavam
inadequados ou ausentes. Este trabalho tem que ser intensificado em relação ao
programa ALFA e deverá servir de base para os próximos programas e projetos
empreendidos pela empresa.

O gerenciamento de riscos dos projetos da empresa XYZ consiste em

basicamente identificar os riscos, classificá-los, acompanhá-los e gerenciá-los da
forma que é possível. As ações de mitigação que envolvem custos em geral não são
realizadas por falta de um orçamento específico do projeto e por limitações
financeiras da empresa. O gestor de projeto fica muito limitado e tem que contar
basicamente com sua capacidade de influência nas instâncias hierárquicas
superiores. A sugestão é que os projetos pudessem contar com um orçamento e
com uma reserva gerencial (por unidade de desenvolvimento) para fazer a mitigação
ou o contingenciamento dos riscos caso estes se transformem em problemas.

Na empresa XYZ temos um departamento dedicado exclusivamente aos

processos da qualidade. Isto deveria ser uma vantagem competitiva, mas a empresa
e os projetos não estão conseguindo usufruir de todos os benefícios que este grupo
poderia oferecer. Várias sugestões são cabíveis neste caso, a primeira é que os
analistas da qualidade verificassem tanto a qualidade do processo quanto a
qualidade do produto. Hoje praticamente só se verifica o processo. A segunda
sugestão é que o grupo da qualidade busque uma padronização interna, de modo
que auditorias realizadas por pessoas diferentes não produzam uma resultado tão
diferente quanto o que podemos observar atualmente. O terceiro é que os analistas
da qualidade aprofundem o seu conhecimento em relação ao negócio do projeto
 102

auditado, para assim conseguir aferir a qualidade em relação ao produto de forma

mais segura. Por fim acredito que o departamento de qualidade deveria coordenar
as equipes de teste e se associar com a equipe de arquitetura para garantir fatores
como cobertura dos testes unitários, execução periódica dos testes unitários e
funcionais, realização de testes de performance com identificação de gargalos e
outras ações que aumentassem a certeza de que o sistema estava pronto para ira
para o ambiente de produção. Com isto seria possível atribuir um conceito a cada
projeto e classificá-los por critérios objetivos em relação à sua adequação aos
padrões de qualidade.

O departamento de desenvolvimento da empresa XYZ utiliza boa parte de seu

tempo e dos seus recursos em projetos e na manutenção dos sistemas gerados
pelos mesmos. Dentro desta perspectiva este departamento deveria adotar uma
estrutura hierárquica projetizada ou pelo menos matricial forte. Infelizmente o modelo
de hierarquia utilizado é o matricial fraco, onde os gerentes de projeto não têm
autoridade hierárquica sobre sua equipe, ficando estes funcionários sob a
responsabilidade do gerente da unidade de desenvolvimento onde são alocados. A
explicação para este fato pode ser dada pela natureza pública da empresa em
questão. A sugestão neste caso é que a empresa altere sua disposição hierárquica,
possibilitando aos gestores do projeto ter atribuições formais de gestão da equipe do
projeto, no período em que o mesmo perdurar.

Hoje a empresa XYZ tem uma grande dificuldade de encontrar bons gestores
para os seus projetos. Acredito que a existam três fatores que mais contribuam para
este fato.

O primeiro fator é que a gestão de projeto não é encarada como uma função
específica. Os funcionários da unidade de desenvolvimento são analistas de sistema
e atuam nesta função, ou seja, você não “é” gestor de projeto, você “está” gestor de
projeto. Esta fragilidade em relação à atuação nos cargos de gestão faz com que os
analistas não se sintam encorajados a estudar e se preparar para assumir a
atribuição de gestor de projetos, pois não terão certeza se atuarão neste papel de
forma perene.

O segundo motivo é a falta de critérios claros para que um analista passe a

ocupar o papel de gerente de projetos e também deixe de ocupá-lo. Atualmente o
critério fundamental é a indicação do gestor da unidade de desenvolvimento que
 103

observa a atuação dos analistas em outros papeis para tentar identificar candidatos
que possam atuar nos cargos de gestão. Esta forma de seleção está bem sujeita ao
efeito halo, onde bons profissionais técnicos são promovidos aos cargos de gestão,
na esperança de quem também venham a ser bons gestores.

O terceiro fator é a falta de um programa de formação de novos gestores.

Além de treinamentos nas técnicas e ferramentas, os candidatos a gestor deveriam
ser treinados no campo comportamental. A maioria dos problemas de projeto exige
um preparo emocional e psicológico para saber contornar situações adversas de
uma forma equilibrada. A sugestão é que se instituísse um programa de formação de
novos gestores, com preparação na teoria de gerenciamento de projetos, nas
ferramentas e na área comportamental. Neste programa, quando os gestores
novatos assumiriam o seu primeiro projeto, contariam com um membro do PMO
atuando em um processo de coaching, podendo assim corrigir e determinar os
rumos da carreira desses profissionais.

Em complemento a este programa, a empresa deveria fazer sistematicamente

treinamentos sobre as boas práticas de gerenciamento de projetos para os membros
da equipe que não tenham interesse imediato em ser gestores. O sentido dessa
sugestão é que é mais fácil contar com a colaboração da equipe se esta sabe como
o gerenciamento de projetos funciona e qual o papel de cada um dentro do projeto.
Isto ajudaria até nos casos onde decisões “desconfortáveis” tivessem que ser
tomadas, pois quando se sabe o motivo destas decisões no contexto do projeto, fica
mais fácil administrar os sentimentos negativos.

Com a implantação do uso do Clarity como SIGP da empresa, é possível

sugerir que todos os relatórios que são solicitados pela gerência imediata e pelos
órgãos de staff sejam concentrados nesta ferramenta. Hoje o gerente de projetos
precisa produzir manualmente estes relatórios e com isto desperdiça um tempo
importante. Sabemos que a ferramenta pode fornecer tal serviço, mas devido à
imaturidade no uso de suas funções, não foi possível utilizá-la para este fim.

Ainda em relação ao uso do SIGP, outra sugestão é que os projetos passem

a fazer o gerenciamento de custos. Os projetos são geradores de custos, mas
apesar disto eles não têm um orçamento. Os gestores de projeto ficam sem saber
quais são os custos diretos ou indiretos do seu próprio projeto. Desta forma fica
 104

impossível utilizar a técnica de valor agregado (Earned Value Technique) para gerar
indicadores de situação de cronograma e orçamento.

Com a integração entre SIGP e os sistemas de folha de pagamento, sistema

contábil e fiscal será possível determinar os custos diretos e indiretos que cada um
dos projetos tem de uma forma geral e o que ele teve no mês corrente. Desta forma
será possível definir se um projeto está em dia e se tem seus gastos dentro dos
valores planejados.

Todas as sugestões aqui apresentadas foram fruto de um longo tempo de

estudo nas áreas de conhecimento relacionadas a gerenciamento de projeto, de
uma vivência de quase três anos como gerente de projetos na empresa XYZ e de
um período de observação utilizado para coletar dados do programa ALFA que
foram utilizados no desenvolvimento deste trabalho.

Esperamos que a empresa possa analisar as sugestões apresentadas e

empreender esforços para transformá-las em realidade, melhorando assim o cenário
de gerenciamento de projetos do programa ALFA e dos demais projetos da
empresa.
 105

6.4 Conclusões individuais de Rodrigo Garcia Barbosa

A definição de projeto o descreve como um empreendimento temporário, cujo

objetivo é a criação de um produto ou serviço único. A característica de ser
temporário é muito importante, pois todo projeto tem um início e um fim definidos. O
projeto termina quando os objetivos para o qual foi criado são atingidos ou quando
se torna claro que os objetivos do projeto não serão ou não poderão mais ser
atingidos ou a necessidade do projeto não existe mais. Ser único significa que todo
produto ou serviço gerado por um projeto é diferente de outros produtos e serviços.
Os projetos envolvem a realização de algo jamais realizado anteriormente e logo é
único.

Foi avaliado ao longo do deste estudo um conjunto de projetos, conforme

citado anteriormente, nos quais se tinha como objetivo o desenvolvimento de um
software com características próprias, ou seja, único. Possuíam também como
premissa um prazo de atendimento, o qual lhes encaixam perfeitamente na definição
de projeto.

Conjuntos de projetos algumas vezes constituem um programa, que nada

mais é que um grupo de projetos relacionados e gerenciados de uma maneira
coordenada para obter benefícios e controles que não seriam possíveis no
gerenciamento de um único projeto. Aqui se podem destacar algumas limitações da
empresa escolhida para o desenvolvimento isolado do software citado, tais como: o
demasiado tamanho do escopo a ser trabalhado, a limitação de recursos existentes
em cada uma das unidades, e como fator mais importante o prazo de atendimento
estabelecido para a implantação do software. Assim sendo, foi inevitável a divisão do
escopo em vários projetos, visando uma paralelização dos trabalhos, podendo-se
entender desta forma que os projetos iniciaram e evoluíram praticamente na mesma
linha de tempo. O fator a ser considerado é que essa divisão aumentou
consideravelmente a complexidade do controle e da própria execução das atividades
dos projetos.

Fica evidente que, neste cenário, a adoção das boas práticas de algumas
áreas de conhecimento elencadas pelo PMBOK tornam-se bem mais necessárias
que outras, como o caso dos gerenciamentos de integração, comunicação, escopo e
riscos.
 106

A empresa foco do estudo possui algumas características, como visto no

capítulo 3, que tornam a gerência de um projeto um pouco diferenciada. O fator
determinante para essa diferenciação é o caráter público. Junto a esse perfil, são
trazidas algumas complexidades como a burocracia, a estratégia política e as
limitações legais.

Percebeu-se também que, por conta de sua estrutura organizacional, a

adoção das práticas relativas às áreas de gerenciamento de aquisições e de custos
não puderam ser aplicadas. Como citado anteriormente as atividades destas áreas
são de responsabilidade de um departamento específico que centraliza todo o
controle das aquisições e dos custos. As informações sobre os custos do projeto não
são divulgadas adequadamente e nem detalhadas, contribuindo para a má gerencia
desta disciplina dentro dos projetos. Tal fato pôde ser comprovado com as respostas
obtidas na pesquisa realizada. Atividades de controle de custos, sugerida pelo
PMBOK e na qual é possível monitorar o progresso do projeto, não são aplicadas e
o progresso acaba sendo percebido apenas pelo crescimento dos percentuais nos
cronogramas.

Explorando o tema desenvolvimento distribuído, que é outro fator

preponderante no programa analisado, pôde-se perceber que a gerência de
comunicação não foi empregada da melhor forma possível. Diante do cenário
encontrado, de vários projetos trabalhando simultaneamente e em localizações
diferentes, a comunicação deveria ser o fator mais importante na gerência deste
projeto. Como citado pelo PMBOK, atividades de planejamento da comunicação e
distribuição das informações para os stakeholders devem ser respectivamente
elaborados e realizados. Pela enorme quantidade de projetos que compõem o
programa, percebe-se que também é imensa a quantidade de stakeholders
envolvidos no processo. Planos de comunicações deveriam ter sido elaborados e
atualizados durante todo o tempo de vida do projeto. A distribuição das informações
dos projetos concentraram-se em determinados participantes, omitindo a divulgação
para muitos outros interessados. Outro problema que poderia ter sido minimizado
com adoção das atividades citadas logo acima é o desalinhamento estratégico entre
equipes operacionais e grupos gerenciais.

Levando ainda em consideração a questão comunicação, e agregando a

gerência de escopo a este item, vários problemas também foram apresentados. A
 107

distribuição do escopo foi realizada no início do projeto, e várias declarações de

escopo foram elaboradas por seus respectivos gestores. Tal fato foi verificado
também no resultado da pesquisa que indicou que o artefato citado faz parte do
processo de desenvolvimento adotado pela empresa. A questão a ser considerada é
que assinatura do documento pelos principais stakeholders envolvidos nos projetos,
não foi realizada no momento correto, o que também pode ser evidenciado nas
respostas dos questionários aplicados. Tal fato gerou um enorme problema no
programa, pois o cliente não havia formalizado o escopo definido inicialmente. Como
de praxe, ao longo da evolução dos projetos, mudanças foram surgindo, e nas
atividades de verificação do escopo elas foram solicitadas. Em determinado
momento, e por questões ligadas ao setor público e ao tardio aceite do documento
antes citado, estas alterações foram incorporadas ao escopo do projeto, fazendo
com que os esforços para suas realizações não fossem contabilizados. Reforça-se
aqui a ideia de que tanto a formalização da definição inicial do escopo, quanto
atividades de verificação e controle do mesmo são essenciais para o sucesso do
projeto.

Podemos citar também que a distribuição do escopo realizada tornou os

processos de controle e execução bastante complexos. A interdependência entre o
negócio de cada projeto aliado à dificuldade de comunicação, contribuíram para que
muitos espaços vazios surgissem no sistema, provocando frequentes discussões
sobre responsabilidades daquelas regras ausentes no mesmo. Percebe-se mais um
vez que a comunicação clara e constante entre os envolvidos é fator primordial para
um correto alinhamento da direção a ser seguida.

A precária análise inicial dos requisitos em conjunto com a restrição temporal

dos projetos, acarretaram em uma prematura elaboração de estimativas que
acabaram se tornando inalcançáveis. Tais estimativas foram ultrapassadas, visto
que com a ausência de uma base de conhecimento consolidado, as durações das
atividades dos projetos foram imprecisas. Algumas vezes, por conta da característica
empresa pública, os prazos são definidos por questões políticas e os projetos
acabam tendo que se adequar a esta grande restrição. As atividades de gerencia de
tempo realmente são realizadas na empresa, mas o setor público nos traz hoje em
dia a clara percepção de que a morosidade em determinados processos, muitas
vezes por questões legais, atrapalha significativamente o andamento dos projetos.
 108

Falando um pouco de integração, podemos citar que a empresa possui um

processo de desenvolvimento para projetos definido, e conforme resultado da
pesquisa o mesmo é em sua grande parte seguido, fato ratificado pelo nível de
maturidade três, encontrado ao final da pesquisa. O problema encontrado no estudo
realizado é que se trata de um programa. A empresa não possui experiências sobre
gerência de programas, o que ficou evidente quando analisado sob a ótica da
gerência de integração. Podemos citar como exemplo disso a adoção tardia de um
sistema integrado de gerência de projetos. A gestão integrada dos projetos não
funcionava bem, e a consolidação de informações era traumática. A função de
integração a nível do programa se dava através de um projeto central, com um nível
hierárquico de decisão superior aos demais, e que gerenciava o escopo completo do
sistema. Tal projeto tinha como funções primordiais manter os “subprojetos”
trabalhando alinhados com a estratégia da empresa, controlando e coordenando-os.
Um plano de gerenciamento foi elaborado, mas sua manutenção não era realizada
periodicamente, fator que serve de base para uma bom controle e execução das
atividades do projeto. Mais um ponto importante a ser apresentado se refere à
dificuldade de monitoramento e controle do trabalhado realizado. A ausência de
métricas precisas dificultou o monitoramento contínuo e consequentes possíveis
ajustes para o atendimento dos objetivos elencados. Muitas vezes os ajustes
necessários se davam após o atraso acontecido e não como medida de mitigação
do risco. Os ajustes aconteciam através de um processo controlado de mudanças,
mas geralmente em um tempo maior que o necessário devido à burocracia exigida.
A celeridade e a estruturação de um processo mais enxuto de mudança favoreceria
ao fator tempo do projeto.

Tratando dos riscos, podemos elencar inúmeras ações que poderiam ser
tomadas ao longo do projeto. Muitos deles deixaram de ser riscos e tornaram-se
fatos após realizarem-se. Apesar da elaboração de um plano de riscos, e de sua
manutenção em um prazo mensal, as análises quantitativas e qualitativas não eram
realizadas de uma forma cuidadosa. Talvez pela dificuldade obtida em mensurar
impactos a níveis de valores, pois como já citado o controle de custos não era de
responsabilidade do gestor e sua visibilidade era mal divulgada. Tendo um plano de
riscos com análises mal dimensionadas, a chance de obter um plano de ações para
tais riscos mal planejados era grande. Esta disciplina acredito ser uma das mais
 109

relevantes na iniciativa privada, pois reflete impactos principalmente em valores e

tempo, mas não é tratada da mesma forma na iniciativa pública, onde o impacto
culminante a ser sofrido é na credibilidade pública. Acredito que por esta razão a
atenção dada aos riscos levantados pelos projetos foi menor que seu devido valor.

Abordando a área da qualidade, nos deparamos também com problemas

ligados às questões de distribuição geográfica. A empresa, como anteriormente
explanado, possui uma equipe de qualidade em cada unidade de desenvolvimento,
e externa aos projetos. Tal equipe possui uma pequena quantidade de recursos por
unidade, o que acaba impossibilitando uma efetiva realização das atividades perante
os projetos. As atividades de planejamento são executadas em cada projeto como
também o garantia do processo. Planejamentos para esse controle são elaborados e
após a execução das verificações de conformidades, relatórios são emitidos e ações
de correções são solicitadas ao projeto, com responsabilidades e prazos definidos.
O ponto negativo é a garantia do produto. Apesar da disseminação de templates
para a elaboração dos artefatos do projeto, as equipes acima citadas não possuem
fôlego suficiente para a realização desta análise. Como resultado disso, artefatos
com padrões de conteúdos distintos acabam sendo criados. Como agravante, pode-
se citar a diferença cultural entre as unidades, que se encontram em regiões
distintas do país, como também o desnivelamento no nível de cobrança efetuado
nas verificações de conformidade. O resultado obtido é um sistema com uma
despadronização documental. Como o processo de desenvolvimento não possui
informações específicas sobre programas, ajustes na metodologia precisaram ser
realizados. O momento de realização dos ajustes foi tardio, o que acabou resultando
em uma refatoração de documentos que não estava prevista no tempo do projeto.
Assim, a lição aprendida foi que "as regras do jogo" devem ser definidas antes do
seu início, ou seja, a metodologia e os padrões a serem seguidos deverão estar bem
definidos e de forma clara para todos os envolvidos, no início do projeto.

No tocante aos recursos humanos, podemos dizer que a unidade possui uma
estrutura hierárquica matricial fraca, na qual as alocações dos recursos nos projetos
não são decididas pelo gerente do projeto, mas sim pelo gerente da unidade. Apesar
desta limitação, pôde-se observar na pesquisa que os recursos alocados participam
de forma integral em seu respectivo projeto desde o início até o seu término.
Porventura, mudanças relativas aos recursos também são realizadas, de acordo
 110

com a necessidade e prioridade momentânea dos projetos, ponto este apresentado

pelo caráter público da empresa, e que gera como requisito ao gestor a
característica de flexibilização.

O desenvolvimento da equipe, atividades sugerida pelo PMBOK, acontece

sob demanda e nenhum plano de treinamentos é elaborado pela empresa. Fica a
cargo do gestor, a solicitação de cursos para os recursos alocados. A gerencia dos
recursos acontece de forma compartilhada, entre o gestor do projeto e o gerente da
unidade. Isso dificulta um pouco a avaliação funcional e o controle operacional do
recurso. Alinhamentos sobre o desempenho da equipe devem ser realizados
constantemente entre os dois responsáveis.

A empresa possui uma política de recursos limitada, onde algumas pessoas

são favorecidas com a bonificação oferecida em determinados cargos, ou através de
ajudas de custos para a realização de cursos profissionais. O fator público aliado à
força atual política são determinantes nos investimentos realizados dentro destes
benefícios. A consequência desta limitação política é, como comprovado nos
resultados da pesquisa, a migração de profissionais para outras empresas, ou ainda
a procura de cargos bonificados dentro da empresa mesmo que o perfil do
funcionário não seja adequado para aquele cargo. Perdem-se assim bons técnicos e
ganham-se gestores mal preparados. Mais um fato a ser considerado é a frustração
de uma parte dos funcionários, notadamente a porção técnica, que almejam uma
política de recursos humanos meritocrática, o que se é compreensível no ambiente
privado, mas difícil de ser implementado no setor público. Todos os fatores acima
convergem para uma certa insatisfação daqueles não favorecidos percebida na
produtividade dos mesmos.

Como descrito no capítulo 3, a empresa conta com o apoio de um

escritório de projetos centralizado e escritórios locais em cada unidade, realizando
suporte aos projetos e prestando consultoria sobre metodologia, ferramentas e
padronização de processos de gerência. Acredito que o principal problema neste
assunto seja a quantidade de recursos alocada nesta área. Existem 75 projetos
trabalhando no momento, e o suporte a estes fica comprometido pela falta de
profissionais. Outro ponto que passou a evidenciar o crescimento neste apoio foi a
adoção de um SIGP. O sistema permite a disponibilização de todas as informações
relativas aos projetos, como também armazenará uma base de conhecimentos e
 111

históricos dos mesmos. Isso servirá de grande valia para a geração de dados
estatísticos e consequentemente criação ou ajustes de métricas para os projetos.

Este trabalho pôde mostrar as inúmeras dificuldades apresentadas na

gerência de projeto quando temos um cenário envolvendo empresas de setor
público desenvolvendo software de forma distribuída. Foi utilizada uma abordagem
diferente de especificações diretas, ou listagens sobre as ações a serem tomadas
para inibir as dificuldades. A ideia desta conclusão traduz-se em juntamente com a
descrição dos problemas identificados, explorá-los em sua causa e consequência, e
reforçar a adoção daquelas atividades, no meu ponto de vista, sugeridas pelo
PMBOK que trariam um resultado benéfico ou reduziriam o acontecimento dos
problemas identificados.
 112

6.5 Conclusões individuais de Wládia Karina Damasceno Silva

O trabalho apresentado tem como foco principal a sugestão de uso de

algumas boas práticas indicadas no PMBOK, com o intuito de tornar melhor o
gerenciamento de projetos e assim alcançar melhores resultados. Nesse estudo, nos
baseamos num caso real, que retrata um programa de uma empresa pública de TIC
e que tem o desenvolvimento distribuído geograficamente. O reconhecimento dos
problemas baseou-se em duas visões: a análise dos problemas, na ótica dos
autores, uma vez que esses fazem parte do corpo funcional que trabalha no estudo
de caso e a avaliação obtida na pesquisa de campo. Entendemos que muitos
problemas identificados fogem ao escopo do projeto e a solução para estes
problemas dependeria de mudanças organizacionais, portanto nos ateremos apenas
ao que estiver dentro do alcance do programa.

Esperamos como resultado do trabalho, enriquecer a base de conhecimento

da empresa e subsidiar uma proposta de mudança com a inserção das melhorias
sugeridas. O programa ALFA por já estar em execução foi apenas um objeto de
estudo e aplicabilidade das recomendações fica a critério da empresa XYZ ou de
novos trabalhos de pesquisa. Também reconhecemos que a inexperiência da
empresa em trabalhar com programas aliada a renovação tecnológica, novas
contratações e a adequação a um processo de desenvolvimento relativamente novo
foram fatores preponderantes para o surgimento dos problemas identificados.

A escolha das áreas presentes nessa conclusão é fruto de indicações da

literatura utilizada, que reforça a importância das áreas de conhecimento
selecionadas. Também foi fator preponderante nessa escolha, a experiência dos
autores no programa, que puderam traduzir sua vivência como participantes do
programa na análise das situações, facilitando na identificação dos problemas.

Abaixo, encontra-se a análise separada por área de conhecimento. Essa

divisão foi feita com o intuito de deixar esta seção mais organizada e tornar o
entendimento mais fácil, uma vez que as propostas de melhoria serão sempre
direcionadas por área de conhecimento.
 113

 Qualidade

A análise dessa área de conhecimento mostrou-se controversa quando

comparamos a avaliação crítica na ótica dos autores com o resultado da pesquisa de
campo. Nesse contexto, arrazoamos que os motivos que levaram ao surgimento de
distorções são reflexos da aplicação da pesquisa, como explicado anteriormente. A
pesquisa de campo foi aplicada apenas em uma unidade de desenvolvimento, a do
Ceará, enquanto que os autores fizeram sua análise levando em conta todas as
unidades de desenvolvimento relacionadas ao programa ALFA. O reconhecimento
de distorções se agrava principalmente, quando o comparativo é feito entre sites
diferentes, ficando evidente a diferença da produção dos artefatos obrigatórios e a
qualidade de artefatos que efetivamente foram produzidos. Percebemos também
que a atuação da qualidade relacionada ao acompanhamento dos projetos é
variável, refletindo nos aspectos já citados.

Conseguimos identificar que a observação de Wirik (2009), relacionada à

ausência do estabelecimento dos requisitos da qualidade do produto pelos
stakeholders, tornou-se fato no programa ALFA. A criação e mudança de padrões ao
longo do desenvolvimento do programa é uma constante, e a consequência disso é
a alteração de artefatos e código para realinhamento dos projetos às novas
orientações. De acordo com o PMBOK, “Planejar a qualidade é identificar os
requisitos e padrões de qualidade do projeto e do produto, documentando as formas
de verificação de conformidade”. Portanto uma solução aparentemente simples, mas
que pela sua própria natureza precisaria ser muito criteriosa é o estabelecimento dos
padrões de qualidade com os stakeholders do projeto, de forma a gerar um Plano de
Gerenciamento da Qualidade único para o programa e que atendesse a todos os
requisitos legais e desejáveis no início do programa. Outro importante aspecto a ser
avaliado é a garantia da qualidade, que com o planejamento já redefinido, precisaria
apenas cumprir as auditorias dentro do planejado, atentando para o rigor que deve
ser utilizado quando da aferição dos artefatos e produto gerados. Nesse sentido
estaríamos ampliando o espectro de avaliação da qualidade, de garantia do
processo para garantia do processo e produto, ainda que não seja de forma
completa. Como forma de elevar o grau de qualidade do produto, sugerimos
incrementar a garantia da qualidade com atividades de testes e inserir na realização
do controle de qualidade a avaliação dos resultados obtidos com os testes, através
 114

de indicadores que traduziriam o que seria minimamente aceitável nos resultados

para que o produto estivesse dentro do padrão de qualidade estabelecido.

 Escopo

A área de conhecimento escopo apresentou algumas características que

denotou um consenso entre o comparativo da análise dos autores e a pesquisa de
campo.

A não assinatura da declaração de escopo no início dos projetos é o primeiro

problema que vamos abordar, pois a não formalização do escopo do projeto através
da falta na assinatura deste documento traz muitas consequências negativas, tais
como a mudança constante de escopo, sem que isso configure uma solicitação de
mudança e sem a repactuação dos prazos. A assinatura da declaração de escopo
para dar continuidade ao projeto já faz parte do processo da empresa XYZ, então
uma mudança na postura da empresa frente a essa situação é o que seria
necessário para tornar efetiva a obrigatoriedade da assinatura da declaração de
escopo.

Baseado no trabalho da consultoria contratada pela Coordenação de

Informática do Ministério do Governo Federal, o escopo do programa ALFA foi
definido e divido entre os projetos do programa. Ao longo do desenvolvimento dos
projetos, o escopo de alguns projetos foi se mostrando mais complexo e maior do
que se supunha o que fez com que alguns projetos tivessem seu escopo redefinido
e novos projetos surgissem para absorver parte do escopo. De acordo com o
PMBOK, “o gerente de projetos concentra-se nos objetivos especificados do projeto,
enquanto o PMO gerencia as principais mudanças do escopo do programa que
podem ser vistas como possíveis oportunidades para melhor alcançar os objetivos
de negócios”, assim entendemos que um acompanhamento mais efetivo do PMO
poderia dar uma visão mais globalizada do escopo comum entre os projetos, para
evitar o desenvolvimento de soluções alternativas a um mesmo tipo de demanda por
projetos distintos e dar um maior esclarecimento acerca do escopo levantado
ajudando a dirimir dúvidas e incertezas sobre definições.

 Comunicação

O fato de o programa ALFA ser distribuído geograficamente torna o processo

de comunicação mais limitado e, de acordo com o relato na análise dos autores
 115

foram essas limitações as geradoras de vários problemas identificados. Embora a

pesquisa de campo tenha focado em questões relacionadas a essa área de
conhecimento, os pontos elencados na análise dos autores mostraram-se suficientes
para justificar a inclusão dessa área para proposição de melhorias.

A primeira melhoria indicada para essa área de conhecimento seria a

elaboração de um plano de comunicação que incluísse a identificação de todos os
stakeholders do projeto. O plano de comunicação do programa ALFA se limitou a
identificar apenas as equipes dos projetos. A identificação do stakeholders é um
processo que foi relegado a um plano secundário e o seu desenvolvimento
possibilitaria o reconhecimento de stakeholders importantes que poderiam
enriquecer a base de conhecimento do programa. Exemplificando, temos a área de
produtos, que iniciou tardiamente a sua atuação no programa e o reconhecimento
prévio desses stakeholders poderia ter antecipado sua participação no
desenvolvimento do programa e como consequência teríamos contribuições
preciosas. Diante desse exemplo identificamos também a necessidade de mapear
os interesses dos stakeholders, pois a participação do departamento de produtos
ainda que tardia, surpreendeu a muitos, quando consideramos que o corpo funcional
alocado nos projetos e relativamente novo e não conhece a empresa por inteiro e
nem a forma de atuação de alguns setores da empresa.

A política de comunicação acordada com o cliente do programa ALFA e os

ativos organizacionais que definem os canais de comunicação disponíveis refletem
outro viés que deveria ser considerado no plano de comunicação. A política
estabelece que os clientes que estão sediados em Brasília não devem se deslocar
para as unidades de desenvolvimento, então as atividades que dependem de
reuniões presenciais precisam de um agendamento prévio, considerando a
disponibilidade e período de convocação dos clientes. A limitação das salas de
videoconferência também configura um problema que poderia ser contornado com a
criação de uma agenda de reuniões. Esses dois aspectos citados quando incluídos
no plano de comunicação envolvem o cliente na manutenção da agenda de
comunicação e ajuda a gerenciar as expectativas do cliente no tocante a
programação dos contatos.

Quando analisamos o processo “Distribuição da Informação” conseguimos

identificar um alto nível de ruído provocado por situações em que são definidas
 116

estratégias e mudanças significavas envolvendo alguns stakeholders chaves no

processo. O processo normal determina que haja repasse das informações, mas a
observação do programa ALFA demonstrou a ocorrência de situações adversas
onde as informações são disseminadas parcialmente, comprometendo a sua
credibilidade. Para resolver essas questões poderiam ser aplicadas as
recomendações de Wirick (2009) que indica o uso da comunicação redundante e
Junior et al (2009) que sugere a criação de uma base de conhecimento on-line.

A distância física entre os projetos e os clientes combinada a liberação de

versões de frequência mensal contendo inovações e correção de produtos tem
demandado tempo dos gerentes de projeto no sentido gerenciar as expectativas dos
stakeholders. Faz-se necessário para essa situação que a comunicação seja
frequente e que os meios de comunicação sejam bastante explorados, para
participar aos clientes o acompanhamento da evolução dos projetos, inclusive
promovendo prévias do que vai ser apresentado nas novas versões ou mesmo em
propostas ainda não concretizadas.

 Recursos Humanos

Após analisarmos os aspectos dos recursos humanos no âmbito do programa

ALFA, verificamos que muitas ações de melhorias relacionadas a essa área de
conhecimento poderiam ser tomadas, mas pelo objeto do estudo de caso tratar-se
de uma empresa pública as ações no âmbito do projeto tornam-se bastante
limitadas. Mesmo extrapolando o contexto do programa, resolvemos indicar uma boa
prática como forma a conscientizar as áreas envolvidas direta ou indiretamente no
desenvolvimento e acompanhamento dos projetos a seguirem os processos da
empresa. A empresa XYZ possui um processo de desenvolvimento bem definido,
contudo a área de produtos ainda não está adequada ao processo, o que nos faz
crer existe uma resistência às mudanças, pois quando analisamos o histórico da
atuação desse departamento, conseguimos identificar sua importância e o grau de
conhecimento nos processos de negócio. Com a construção do programa ALFA, os
recursos humanos do departamento de produtos foram inseridos num contexto de
inovação tecnológica e mudança nos processos de negócio, demonstrando a
necessidade de um novo aprendizado para absorção dos novos conceitos. O
PMBOK coloca como uma das características do líder a superação na resistência a
mudanças, mas como relatado no início deste tópico, o problema exposto ultrapassa
 117

a barreira do programa, assim compreendemos que esse tipo de atuação seria uma
tarefa para atuação conjunta do PMO e área de Pessoas. A ideia é o PMO difundir
com mais ênfase o processo da empresa e os ganhos obtidos com ele. A área de
Pessoas seria responsável em conduzir dinâmicas e demais treinamentos
necessários para tornar os recursos receptivos a mudanças.

Continuando a análise nessa área de conhecimento, abordamos na seção

sobre a análise crítica da empresa a existência da gratificação designada ao gestor
do projeto. Hoje essa é a única bonificação existente que é individualizada e
direcionada exclusivamente aos projetos. A falta de uma bonificação individual e que
premie de forma diferenciada os recursos que tiverem um maior destaque pelo seu
desempenho dentro dos projetos ainda causa frustração. A implementação dessas
mudanças depende de uma redefinição dos objetivos estratégicos da empresa, que
apesar de não configurar uma ação fácil, uma vez que nem toda empresa trabalha
de forma projetizada, ainda é uma ação esperada.

Hoje a atuação do PMO junto aos projetos é de assessoria e

acompanhamento. Com o advento do programa na empresa XYZ, ficou evidente a
necessidade de uma participação mais ativa do PMO, ampliando o seu papel para
promover uma coordenação e regulação dos projetos e das áreas que atuam junto
aos projetos. Entendemos que o gerente de projeto acumula muitas funções no que
diz respeito ao relacionamento e atendimento das necessidades do cliente, que na
verdade configura um papel de outras áreas, quando a questão é analisada através
da ótica do processo de desenvolvimento da empresa. Uma boa prática seria
promover a atuação do PMO na orientação e regulação a atuação das áreas dentro
do processo de desenvolvimento. Confrontando essa proposta com o corpo
funcional existente no PMO, identificamos que um limitador é o quantitativo do corpo
funcional do PMO. O número obtido mostra-se inadequado para atendimento a
todos os projetos existentes nas unidades de desenvolvimento. Assim, propomos
também que o PMO seja expandido, através da contratação de novos recursos para
promover uma aproximação dos projetos e obter melhores resultados.
 118

7. POSSÍVEIS DESDOBRAMENTOS

As diferenças entre projetos são inúmeras, e a mudança de algumas simples

características nos mesmos poderão requerer soluções diversas. Contudo, reunindo
as três características chaves apontadas ao longo do trabalho: desenvolvimento de
software, distribuído, em uma empresa pública, verifica-se que tendem a apresentar
problemas e dificuldades significativos em algumas das áreas de conhecimento
elencadas pelo PMBOK, as quais acabam por ser determinantes no sucesso do
projeto.

Como o trabalho visa analisar uma situação real, com seus problemas e
desafios relativos ao gerenciamento de projetos, em uma empresa pública de TIC,
propondo boas práticas e melhorias, estas propostas poderão vir a serem adotadas
efetivamente pela própria empresa na qual se baseou o presente trabalho, bem
como servir de subsídio para empresas que vivenciem situações semelhantes.

Além do benefício citado, este trabalho poderá servir como subsídio para
profissionais e interessados na área de gerenciamento de projetos, uma vez que
descreve na prática a forma como as áreas de conhecimento estão sendo
trabalhadas em projetos deste porte e características.
 119

8. REFERÊNCIAS BIBLIOGRÁFICAS

ANSOFF, H. I. A. Administração Estratégica. São Paulo: Ed. Atlas, 1990.

AUDY, Jorge; PRIKLADNICKI Rafael. Desenvolvimento distribuído de software.

Rio de Janeiro: Elsevier, 2007.

BARCAUI, André. O desafio do sucesso em projetos de tecnologia da

informação. Disponível em: http://www.bbbrothers.com.br/scripts/Artigos/Artigo%20-
%20Sucesso%20em%20Projetos%20TI.pdf. Acesso em: 29/04/2011.

BAROFF, L. E. Distributed teaming on JPL projects. In: IEE AEROSPACE

CONFERENCE, 2002, Montana. Proceedings... Washington D.C.: IEEE Computer
Society Press, 2002.

CARMEL, E. Global Software Teams – Collaborating Across Borders and Time -

Zones. New Jersey: Prentice Hall, 1999.

CARNEIRO, Margareth F. Santos. Gestão Pública: o papel do planejamento

estratégico, programas e projetos e dos escritórios de projetos na modernização da
gestão pública. Rio de Janeiro: Brasport, 2010.

COSTA, Catarina de Souza. Uma abordagem baseada em evidências para o

gerenciamento de projetos no desenvolvimento distribuído de software. 2010.
170f. Dissertação (Mestrado em Ciência da Computação) – Centro de Informática,
Universidade Federal de Pernambuco, Recife.

DINSMORE, P. C.; NETO, F. H. S. Gerenciamento de projetos e o fator humano:

conquistando resultados através das pessoas. Rio de Janeiro: Qualitymark, 2005.

HUZITA, E. et al. Um conjunto de soluções para apoiar o desenvolvimento

distribuído de software. In: Workshop de Desenvolvimento Distribuído de Software,
n. 2, Campinas. Anais... São Paulo: SBC, 2008.

INSTITUTO BRASILEIRO DE GEOGRAFIA E ESTATÍSTICA (IBGE). Pesquisa de

Serviços de Tecnologia da Informação – 2009. Rio de Janeiro: IBGE, 2011.

JAQUES, Tim. Project Management: A Lever of Change in the Public Sector.

Disponível em: http://www.pmi.org/eNews/Post/2009_12-04/PM-A-Lever-of-Change-
in-the-Public-Sector.html. Acesso em: 30/04/2011.
 120

JUNQUEIRA, Álvaro R. B.. Implementação de Projetos de Governo Eletrônico

com Múltiplas Agências: uma análise dos fatores críticos de sucesso do projeto
Nota Fiscal Eletrônica sob a ótica do PMBOK. 2007. 232f. Dissertação (Mestrado em
Administração de Empresas) - Escola de Administração de Empresas de São Paulo,
FGV, São Paulo.

JUNIOR, Ivaldir H. de F. et al. Proposta de Boas Práticas no Processo de

Comunicação em Projetos Distribuídos. In: Workshop de Desenvolvimento
Distribuído de Software, n. 3, Fortaleza. Anais... São Paulo: SBC, 2009.

KAROLAK, D. W. Global Software Development – managing virtual teams and

environments. Washington D.C.: IEEE Computer Society Press, 1998.

KRIGSMAN, Michael. "Technically sound / well-trained bodies". Disponível em:

http://www.zdnet.com/blog/projectfailures/technically-sound-well-trained-
bodies/368?tag=mantle_skin;content. Acesso em: 25/05/2011.

KERZNER, Harold. Gestão de Projetos – As melhores práticas. Porto Alegre:

Bookman, 2002.

KERZNER, Harold. Project management: a systems approach to planning,

scheduling, and controlling. New Jersey: Wiley, 2003.

LEAL, Gislaine C. L. Uma abordagem integrada de desenvolvimento e teste de

software para equipes distribuídas. 2010. 195f. Dissertação (Mestrado em Ciência
da Computação) - Departamento de Informática, Universidade Estadual de Maringá,
Maringá.

LEAL, Gislaine C. L. et al. Recomendações para a Gestão do Desenvolvimento de

Software com Equipes Distribuídas. In: Workshop de Desenvolvimento Distribuído de
Software, n. 4, S. Anais... São Paulo: SBC, 2010.

LEME, Lafaiete Henrique Rosa. Uma estratégia para apoiar gerenciamento de

risco em um ambiente distribuído de desenvolvimento de software. 2007. 108f.
Dissertação (Mestrado em Ciência da Computação) - Departamento de Informática,
Universidade Estadual de Maringá, Maringá.

LOPES, João Carlos dos Santos. Políticas públicas para Tecnologia da

Informação e comunicação: A adoção de soluções abertas e softwares públicos:
 121

"O caso Dataprev". 2009. 47f. Monografia (Especialização em Gestão Pública) -

Escola Nacional de Administração Pública, ENAP, Brasília.

MARTELANE, R. O relacionamento entre os corpos permanentes e não-

permanentes na organização pública — um modelo. In: REUNIÃO ANUAL DA
ANPAD, 15., 1991, Salvador, BA, Anais... Salvador: ANPAD, 1991.

MACIEL, Ricardo Dias. Gestão de projetos em empresas de pequeno e médio porte:

Um estudo dos fatores de (in)sucesso. MundoPM, n. 35, p. 30-37, out. / nov. 2010.

MEDEIROS, Carlos Augusto de. Estatística aplicada à educação. Brasília:

Universidade de Brasília, 2007.

NIDIFFER, Kenneth E.; DOLAN, Dana. Evolving Distributed Project Management.

IEEE Software, vol. 22, n. 5, p. 63-72, set. / out. 2005.

ORTOLANI, L. F. B. Indicadores do uso de TI na Administração Pública para

Planejamento de Informática. In: SEMINÁRIO NACIONAL DE INFORMÁTICA
PÚBLICA, 25., 1997, Salvador. Anais... Salvador, 1997.

PAGNO, Rodrigo Tomaz. Uma ferramenta de estimativa de custos para o

Desenvolvimento Distribuído de Software. 2010. 172f. Dissertação (Mestrado em
Ciência da Computação) - Departamento de Informática, Universidade Estadual de
Maringá, Maringá.

PASSOS, Maria Luiza G. de Souza. Gerenciamento de Projetos para Pequenas

Empresas: combinando boas práticas com simplicidade. Rio de Janeiro: Brasport,
2008.

PIRES, José C. de S.; MACEDO, Kátia B.. Cultura organizacional em organizações

públicas no Brasil. Revista de Administração Pública, vol. 40, n. 11, p. 81-105, jan.
/ fev. 2006.

PRADO, Darci. O que é sucesso? MundoPM, n. 12, p. 53-58, dez. 2006 / jan. 2007.

PRADO, Darci; ARCHIBALD, Russell. Maturidade Brasil 2010 – Pesquisa sobre

Maturidade e Sucesso em Gerenciamento de Projetos de Sistemas de
Informação (Software). Disponível em:
http://www.maturityresearch.com/novosite/2010/downloads/PesquisaMaturidade2010
_Relatorio-T%20I%20_Completo_V3.pdf. Acesso em: 07/09/2011.
 122

PRESSMAN, Roger S. Engenharia de Software. 6. ed. São Paulo: McGraw-Hill,

2006.

PRESSMAN, Roger S. Software engineering: a practitioner's approach. 7. ed.

New York: McGraw-Hill, 2010.

PROJECT MANAGEMENT INSTITUTE (PMI). Um Guia do Conjunto de

Conhecimentos do Gerenciamento de Projetos – PMBOK (Project Management
Body of Knowledge Guide). Philadelphia: PMI, 2008.

ROBERTSON, Ken. Project Management Maturity Model. Disponível em

http://www.klr.com/articles/Articles_PMO_pm_maturity_model.pdf. Acesso em
04/06/2011

ROSA, Marcelo Ozorio. Gerenciamento de Projetos em Instituições Públicas.

Disponível em:
http://www.pmies.org.br/clickadmin/midias/data/Gerenciamento_de_Projetos_em_Ins
tituicoes_Publicas.pdf. Acesso em: 03/06/2011.

SIQUEIRA, Fábio L.; SILVA, Paulo S.. Recomendações para a Gerência de Projetos
no Desenvolvimento Distribuído de Software. In: SIMPÓSIO BRASILEIRO DE
QUALIDADE DE SOFTWARE, 5., 2006, Vila Velha. Anais... São Paulo: SBC, 2006.

SOLER, Alonso Mazini. Maturidade Organizacional e o Modelo PMI-OPM3.

MundoPM, nº.2, abr. / mai. 2005.

SOUZA, Diarley C. S. et al. Um Processo de Gerência de Comunicação Baseada no

PMBOK para o Desenvolvimento Distribuído de Software. In: SIMPÓSIO
BRASILEIRO DE QUALIDADE DE SOFTWARE, 5., 2006, Vila Velha. Anais... São
Paulo: SBC, 2006.

SOUZA, Maria C. P.; FERREIRA, Raquel Nilo. O desafio de um Escritório de

Projetos em uma empresa pública: Foco em Pessoas. 2006. 68f. Monografia
(Especialização em Gerência de Projetos) - Fundação Getúlio Vargas, Rio de
Janeiro.

TAIT, Tania Fatima Calvi. Um Modelo de Arquitetura de Sistemas de Informação

para o Setor Público: estudo em empresas estatais prestadoras de serviços de
informática. 2000. 263f. Dissertação (Doutorado em Engenharia de Produção) -
 123

Departamento de Engenharia de Produção, Universidade Federal de Santa Catarina,

Florianópolis.

TAVOLARO, S. B. F. Movimento Ambientalista e Modernidade: Sociabilidade,

Risco e Moral. São Paulo: Annablume/Fapesp, 2001.

XAVIER, Carlos Magno da Silva et al. Gerenciamento de aquisições em projetos.

2. ed. Rio de Janeiro: FGV, 2010.

WILLCOCKS, Leslie. Managing Information Systems in UK Public Administration:

issues and prospects. Public Administration, v.72, n. 1, p.13-32, Março 1994.

WIRICK, David W. Public-sector project management: meeting the challenges

and achieving results. New Jersey: Wiley, 2009.

ZANONI Roberto; AUDY, Jorge Luís Nicolas. Projected Management Model for
Physically Distributed Software Development Environment. In: ANNUAL HAWAII
INTERNATIONAL CONFERENCE ON SYSTEM SCIENCES, 36., Hawaii.
Proceedings... Washington D.C.: IEEE Computer Society Press, 2003.
 124

9. GLOSSÁRIO

Adjudicação - É o ato final do procedimento administrativo de licitação. Constitui o

ato declaratório, pelo qual a mesma autoridade pública competente para homologar,
atribui de maneira formal ao vencedor do certame o objeto da licitação.

Earned Value Technique - Termo em inglês para técnica de valor agregado. A

técnica do valor agregado consiste na comparação de três curvas de desempenho:
Custo Orçado do Trabalho Agendado, Custo Orçado do Trabalho Realizado e Custo
Real do Trabalho Realizado. A TVA é utilizada para relatar o estado do projeto em
termos de custo e tempo, o que permite uma visão holística do progresso do projeto.

Sponsor - Patrocinador; patrono, padrinho, responsável.

Stakeholder - O termo inglês stakeholder designa uma pessoa, grupo ou

organizações que estão ativamente envolvidos no projeto ou cujos interesses
possam ser positiva ou negativamente afetados pelo projeto ou em seus resultados.
Estão incluídos nos stakeholders os funcionários, gestores, proprietários,
fornecedores, clientes, credores, Estado (enquanto entidade fiscal e reguladora),
sindicatos e diversas outras pessoas ou entidades que se relacionam com a
empresa.

PMO - Escritório de Gerenciamento de Projetos - O Escritório de Projetos ou

Project Management Office (PMO), é uma entidade criada dentro ou fora das
organizações e caracterizada como uma central de gerenciamento de projetos,
podendo-se dizer que são o “quartel general” dos projetos.

SIGP – É uma sigla ou acrônimo para o nome “sistema integrado de gerenciamento

de projetos”
 125

10. APÊNDICES
10.1 Apêndice 1

*Obrigatório

Todas as questões podiam ser respondidas com as seguintes opções:

0 1 2 3 4 5
1. Os projetos têm um gerente de projeto formalmente designado que participa desde a fase de
autorização do projeto? *
2. Os projetos têm um termo de abertura formalmente assinado pelos principais stakeholders? *
3. Os projetos têm uma declaração de escopo assinada antes do início efetivo do projeto? *
4. Os projetos mantêm um plano de projeto com os principais artefatos de planejamento do
projeto? *
5. O processo institucional e unificado de gestão de projetos é utilizado pelos projetos da empresa?
*
6. Os planos dos projetos são constantemente atualizados? *
7. O projeto tem um sponsor (patrocinador) formalmente designado e ciente das suas
responsabilidades? *
8. Existe um escritório de projetos, com membros experientes, que dê suporte aos projetos da
empresa? *
9. Os projetos da empresa utilizam um sistema de gerenciamento de projeto (SGP)? *
10. A empresa possui um sistema integrado de controle que permita monitorar os projetos? *
 126

11. Os projetos têm um controle integrado de mudança formalmente definido e efetivamente

adotado? *
12. As alterações nas linhas de base do projeto são previamente analisadas e aprovadas por um
comitê de controle de mudanças? *
13. Os projetos mantêm uma EAP (Estrutura analítica do Projeto) com os pacotes das principais
entregas? *
14. A EAP e a declaração de escopo são validadas pelos principais stakeholders para determinar se
contém todo e o trabalho necessário para o projeto e somente o trabalho realmente necessário?
*
15. Ao definir o escopo, são buscadas alternativas para os itens mais críticos em relação a prazos,
custos e riscos? *
16. O escopo do projeto é periodicamente verificado para se determinar se ainda atende as
necessidades dos stakeholders? *
17. São consultados especialistas ou o planejamento de projetos similares para se determinar o
escopo de um novo projeto? *
18. A equipe do projeto é formalmente designada no início do projeto? *
19. A maioria da equipe dos projetos é alocada em tempo integral? *
20. O tamanho da equipe do projeto é baseado no esforço necessário para a realização do projeto?
*
21. O gestor do projeto tem autoridade para decidir sobre a permanência ou liberação de membros
da equipe do projeto? *
22. A equipe do projeto é adequadamente treinada ou domina as ferramentas e técnicas que serão
necessárias no projeto? *
23. As equipes dos projetos têm treinamento nas práticas de gerenciamento de projeto? *
24. Os projetos têm uma matriz de responsabilidade? *
25. Os planos de projetos contêm um orçamento aprovado pelos stakeholders? *
26. O gestor do projeto é responsável pelos processos de aquisição dentro do projeto? *
27. O gestor do projeto é responsável pelo orçamento do projeto e por sua execução conforme o
planejamento? *
28. As aquisições feitas junto a outras áreas da empresa são formalizadas? *
29. Na empresa existe um processo definido para a seleção de fornecedores externos? *
30. Os fornecedores externos à empresa são periodicamente avaliados? *
31. Os riscos dos projetos são analisados qualitativamente? *
32. Os projetos realizam análise do impacto dos riscos para compor o cronograma e o orçamento do
projeto? *
33. Os projetos contam com reservas gerenciais e de contingência para os casos de materialização
de riscos não tratados? *
34. O cliente é orientado em relação aos riscos do projeto e os tratamentos adotados? *
35. As oportunidades também são analisadas (riscos positivos)? *
Os riscos e oportunidades são revisados periodicamente nos projetos da empresa? *

36. Todas as atividades do projeto constam no cronograma? *

37. Os projetos têm controle de performance de tempo e de custos baseado nas técnicas de valor
agregado (Earned Value) ? *
38. A estimativa de esforço das atividades tem a participação e a anuência da equipe do projeto? *
39. A atribuição dos recursos humanos para as atividades é feita levando em consideração o
calendário real dos recursos, considerando-se férias, ausências, feriados, treinamentos e outros
similares? *
40. As estimativas das atividades são baseadas no tempo real necessário para a execução das
mesmas? *
41. Existe uma equipe externa ao projeto para avaliar e orientar sobre as questões de qualidade? *
42. Os acordos de níveis de serviço são definidos em contrato com o cliente? *
43. São realizadas auditorias de qualidade frequentes por uma equipe externa ao projeto? *
44. Existe uma definição no nível de qualidade esperado para o projeto e para o produto produzido
pelo mesmo? *
45. Existe um mecanismo de controle das não conformidades encontradas no projeto durante as
avaliações de qualidade? *
46. Avaliações de qualidade com não conformidades impactam as entregas do projeto? *
47. É realizada a identificação e avaliação dos stakeholders do projeto? *
48. Existe um plano de comunicação onde a forma de distribuição das informações é registrada? *
 127

49. Existe um mecanismo de distribuição das informações que garanta que as mesmas foram
recebidas pelos seus destinatários? *
50. São gerados relatórios periódicos de desempenho para o projeto? *
51. O cliente é instruído sobre sua participação no processo de desenvolvimento do sistema? *
52. As reuniões dos projetos são documentadas em ata? *
53. São realizadas reuniões periódicas de revisão, acompanhamento e validação com o cliente? *
54. Os projetos da empresa registram lições aprendidas? *
55. Os projetos da empresa conseguem reusar lições aprendidas de outros projetos? *
56. Os gerentes de projeto demonstram ter experiência suficiente para exercer suas funções? *
57. Os gerentes de projeto possuem autoridade suficiente para exercer suas funções? *
58. Os gerentes de projeto são avaliados periodicamente pelos seus superiores hierárquicos ou pelo
escritório de projetos? *
59. Existe na empresa uma base de conhecimento de gerenciamento de projeto para apoiar os
gestores? *

10.2 Apêndice 2

Todas as questões podiam ser respondidas com as seguintes opções:

0 1 2 3 4 5
1. Indique o seu grau de conhecimento teórico em gerência de projeto. *
2. Indique o seu grau de conhecimento sobre as praticas de gerencia de projetos abordadas pelo
Project Management Body of Knowledge (PMBOK). *
3. Indique o seu grau de conhecimento sobre os grupos de processos (Iniciação, Planejamento,
Execução, Monitoramento e Controle, Fechamento) elencados pelo PMBOK. *
4. Indique o seu grau de conhecimento sobre o ciclo de iterações (melhoria contínua) entre os
processos definido pelo PMBOK chamado PDCA ou Ciclo de Deming (Planejar, Executar,
verificar e Agir). *
5. Indique o seu grau de conhecimento sobre os processos e artefatos pertencentes à área de
conhecimento de Gerencia de Escopo descrita pelo PMBOK. *
 128

6. Indique o seu grau de conhecimento sobre os processos e artefatos pertencentes à área de

conhecimento de Gerencia de Qualidade descrita pelo PMBOK. *
7. Indique o seu grau de conhecimento sobre os processos e artefatos pertencentes à área de
conhecimento de Gerencia de Tempo descrita pelo PMBOK. *
8. Indique o seu grau de conhecimento sobre os processos e artefatos pertencentes à área de
conhecimento de Gerencia de Custos descritos pelo PMBOK. *
9. Indique o seu grau de conhecimento sobre os processos e artefatos pertencentes à área de
conhecimento de Gerencia de Recursos Humanos descritos pelo PMBOK. *
10. Indique o seu grau de conhecimento sobre os processos e artefatos pertencentes à área de
conhecimento de Gerencia de Aquisições descrita pelo PMBOK. *
11. Indique o seu grau de conhecimento sobre os processos e artefatos pertencentes à área de
conhecimento de Gerencia de Riscos descritos pelo PMBOK. *
12. Indique o seu grau de conhecimento sobre os processos e artefatos pertencentes à área de
conhecimento de Gerencia de Comunicações descrita pelo PMBOK. *
13. Indique o seu grau de conhecimento sobre os processos e artefatos pertencentes à área de
conhecimento de Gerencia de Integração descrita pelo PMBOK. *
14. Indique o seu grau de conhecimento sobre feedback. *
15. Tendo como base seus conhecimentos e suas características pessoais, que grau de liderança
você acredita que exerce sobre sua equipe? *
16. Indique o número de projetos que você já gerenciou antes do projeto atual. *
17. Indique o tamanho/porte médio dos projetos já gerenciados por você. *
18. Qual o nível de satisfação você acredita ter obtido junto ao cliente em projetos já gerenciados
anteriormente? *
19. Os projetos gerenciados por você anteriormente foram concluídos dentro do prazo estimado? *
20. Os projetos gerenciados por você anteriormente foram concluídos dentro do custo orçado
(dentro do orçamento)? *