DANIELE MARTINS
FERNANDO REZENDE CELESTINO
JOÃO OSWALDO MAZUR
MARCELO STIVAL
WALTER RIBEIRO DE OLIVEIRA JR
A ANÁLISE DA MATURIDADE E RECOMENDAÇÕES DE
MELHORES PRÁTICAS DE GERENCIAMENTO DE
PROJETOS EM EMPRESAS DE PEQUENO PORTE DE
DESENVOLVIMENTO DE SOFTWARE.
Trabalho apresentado ao curso MBA em Gerência de Projetos, Pós-Graduação lato sensu, da Fundação Getúlio Vargas como requisito parcial para a obtenção do Grau de Especialista em Gerência de Projetos.
ORIENTADOR: Prof. Denise Basgal
Curitiba
Março / 2009
FUNDAÇÃO GETULIO VARGAS
PROGRAMA FGV MANAGEMENT
MBA EM GERÊNCIA DE PROJETOS
O Trabalho de Conclusão de Curso
“A ANÁLISE DA MATURIDADE E RECOMENDAÇÕES DE MELHORES PRÁTICAS
DE GERENCIAMENTO DE PROJETOS EM EMPRESAS DE PEQUENO PORTE DE
DESENVOLVIMENTO DE SOFTWARE”
elaborado por DANIELE MARTINS, FERNANDO REZENDE CELESTINO, JOÃO
OSWALDO MAZUR, MARCELO STIVAL e WALTER RIBEIRO DE OLIVEIRA JR
e aprovado pela Coordenação Acadêmica do curso de MBA em Gerência de Projetos, foi
aceito como requisito parcial para a obtenção do certificado do curso de pós-graduação, nível
de especialização do Programa FGV Management.
Curitiba, 18 de março de 2009
Carlos A. C. Salles
Jr.
Coordenador
Acadêmico
Executivo
Prof. Denise Basgal
DECLARAÇÃO
A empresa Wasys Tecnology, representada neste documento pelo Sr.(a) JOÃO OSWALDO
MAZUR, Sócio-Diretor, autoriza a divulgação das informações e dados coletados em sua
organização, na elaboração do Trabalho de Conclusão de Curso intitulado “A ANÁLISE DA
MATURIDADE E RECOMENDAÇÕES DE MELHORES PRÁTICAS DE
GERENCIAMENTO DE PROJETOS EM EMPRESAS DE PEQUENO PORTE DE
DESENVOLVIMENTO DE SOFTWARE”, realizados pelos alunos DANIELE MARTINS,
FERNANDO REZENDE CELESTINO, JOÃO OSWALDO MAZUR, MARCELO STIVAL
e WALTER RIBEIRO DE OLIVEIRA JR, do curso de MBA em Gerência de Projetos, do
Programa FGV Management, com o objetivo de publicação e/ ou divulgação em veículos
acadêmicos.
Curitiba, 14 de Janeiro de 2009.
JOÃO OSWALDO
MAZUR
Sócio-Diretor
Wasys Tecnology
TERMO DE COMPROMISSO
Os alunos DANIELE MARTINS, FERNANDO REZENDE CELESTINO, JOÃO
OSWALDO MAZUR, MARCELO STIVAL e WALTER RIBEIRO DE OLIVEIRA JR,
abaixo assinados, do curso de MBA em Gerência de Projetos, Turma 02/2007 do Programa
FGV Management, realizado nas dependências do Instituto Superior de Administração e
Economia - ISAE/FGV, no período de 08/2007 a 02/2009, declaram que o conteúdo do
Trabalho de Conclusão de Curso intitulado “A ANÁLISE DA MATURIDADE E
RECOMENDAÇÕES DE MELHORES PRÁTICAS DE GERENCIAMENTO DE
PROJETOS EM EMPRESAS DE PEQUENO PORTE DE DESENVOLVIMENTO DE
SOFTWARE”, é autêntico, original e de sua autoria exclusiva.
Curitiba, 09 de março de 2009.
DANIELE
MARTINS
FERNANDO
REZENDE
CELESTINO
JOÃO OSWALDO
MAZUR
MARCELO
STIVAL
WALTER RIBEIRO
DE OLIVEIRA JR
Dedicamos este trabalho a todos os que
nos acompanharam e apoiaram durante este MBA:
familiares, amigos, professores e colegas.
RESUMO
O desenvolvimento e aplicação de processos formais de gerenciamento de projetos é um
grande passo no aumento da probabilidade de sucesso dos projetos. As empresas têm buscado
aprimorar estes processos e adotar modelos de maturidade e suas recomendações de boas
práticas. O objetivo deste trabalho é apresentar uma forma de medição do nível de maturidade
de empresas de pequeno porte no processo de desenvolvimento de software e, a partir do nível
atingido, sugerir uma seleção de boas práticas. Com isto espera-se que haja aprimoramento
em seus processos de gerenciamento de projetos e melhoraria em seu grau de maturidade. O
modelo de maturidade utilizado como referência neste trabalho é o OPM3, proposto pelo
PMI.
Palavras Chave: gerenciamento de projetos, maturidade, OPM3, empresa de pequeno porte,
melhores práticas.
ABSTRACT
Development and application of formal process of project management is a great step forward
the increase of success probability in projects. Companies have searched for improving in
these processes and adopted maturity models and their good practices recommendations. The
goal of this study is to present one way to measure the maturity level of small size companies
in the software development process and, from the measured level, suggest a selection of best
practices. With this we hope that the company improves its project management process and
its maturity level. The adopted maturity model was the OPM3, proposed by the PMI.
Key Words: project management, maturity, OPM3, small size company, best practices.
AGRADECIMENTOS
Agradecemos a todo apoio e incentivo recebido da professora Denise Basgal durante a
elaboração dos trabalhos para apresentação nos fóruns e orientação dada para
elaboração deste trabalho de conclusão de curso.
Agradecemos a todos os professores que, ao longo de um ano e meio, transmitiram-nos
sua experiência em gerência de projetos.
Agradecemos às nossas empresas, por terem nos apoiado e estimulado a cursar este
MBA.
Agradecemos, por fim, a nossos familiares e amigos, que nos apoiaram durante todo o
curso.
SUMÁRIO
1 INTRODUÇÃO....................................................................................................................151.1 CONSIDERAÇÕES INICIAIS......................................................................................................15
2 FUNDAMENTAÇÃO TEÓRICA......................................................................................172.1 O QUE É MATURIDADE EM GERENCIAMENTO DE PROJETOS.........................................17
2.2 MODELOS DE MATURIDADE EM GERENCIAMENTO DE PROJETOS...............................20
2.2.1 Modelo Prado - MMGP.............................................................................................................20
2.2.2 Modelo CMMI...........................................................................................................................22
2.2.3 O OPM3......................................................................................................................................23
2.2.4 Outros modelos..........................................................................................................................25
3 METODOLOGIA CIENTÍFICA.......................................................................................263.1 CONSIDERAÇÕES INICIAIS......................................................................................................26
3.2 A EMPRESA..................................................................................................................................26
3.3 O CONTEXTO...............................................................................................................................26
3.4 O OBJETIVO.................................................................................................................................27
3.5 O CENÁRIO ALVO......................................................................................................................27
3.6 A ESCOLHA DO MODELO DE MATURIDADE........................................................................28
3.7 A ADEQUAÇÃO DO MODELO OPM3.......................................................................................29
3.8 O MODELO SUGERIDO..............................................................................................................30
4 ANÁLISE DOS RESULTADOS.........................................................................................334.1 CONSIDERAÇÕES INICIAIS......................................................................................................33
4.2 RESULTADOS..............................................................................................................................33
4.3 DISCUSSÃO DOS RESULTADOS..............................................................................................35
4.3.1 Integração...................................................................................................................................35
4.3.2 Escopo.........................................................................................................................................41
4.3.3 Tempo.........................................................................................................................................45
4.3.4 Custo...........................................................................................................................................46
4.3.5 Qualidade...................................................................................................................................51
4.3.6 Recursos Humanos....................................................................................................................53
4.3.7 Comunicação..............................................................................................................................57
4.3.8 Riscos..........................................................................................................................................58
4.3.9 Aquisições...................................................................................................................................59
5 CONCLUSÕES....................................................................................................................63
6 POSSÍVEIS DESDOBRAMENTOS..................................................................................65
7 REFERÊNCIAS BIBLIOGRÁFICAS...............................................................................66
8 APÊNDICES.........................................................................................................................688.1 APÊNDICE I – LISTA DE PERGUNTAS....................................................................................68
8.2 APÊNDICE II – LISTA DE BOAS PRÁTICAS............................................................................88
8.3 APÊNDICE III – LISTA DE CORRESPONDÊNCIA ENTRE PERGUNTAS E BOAS
PRÁTICAS........................................................................................................................................130
8.4 APÊNDICE IV – LISTA DE PERGUNTAS E BOAS PRÁTICAS.............................................133
8.5 APÊNDICE V: MODELOS DE DOCUMENTOS.......................................................................144
8.5.1 Integração.................................................................................................................................144
8.5.2 Escopo.......................................................................................................................................149
8.5.3 Custos.......................................................................................................................................152
8.5.4 Qualidade.................................................................................................................................156
8.5.5 Recursos Humanos..................................................................................................................159
8.5.6 Comunicação............................................................................................................................160
8.5.7 Riscos........................................................................................................................................161
8.5.8 Aquisições.................................................................................................................................163
8.6 APÊNDICE VI: QUESTIONÁRIO RESPONDIDO PELA EMPRESA......................................165
9 APÊNDICES POR AUTOR INDIVIDUAL....................................................................1689.1 DANIELE MARTINS..................................................................................................................168
9.2 FERNANDO REZENDE CELESTINO.......................................................................................172
9.3 JOÃO OSWALDO MAZUR........................................................................................................181
9.4 MARCELO STIVAL...................................................................................................................194
9.5 WALTER RIBEIRO DE OLIVEIRA JR......................................................................................198
LISTA DE TABELAS
TABELA 1: CATEGORIAS DE NÍVEL DE MATURIDADE..........................................18
TABELA 2: RELAÇÃO DE PESOS VERSUS UTILIZAÇÃO.........................................31
TABELA 3: RELAÇÃO DAS ÁREAS DE CONHECIMENTO........................................31
TABELA 4: RELAÇÃO DAS ESTÁGIOS..........................................................................32
TABELA 5: RESULTADOS POR ÁREA DE CONHECIMENTO..................................33
TABELA 6: RESULTADOS DOS ESTÁGIOS DE MATURIDADE................................34
TABELA 7: INDICADORES EVA.......................................................................................48
LISTA DE FIGURAS
FIGURA 1: DISTRIBUIÇÃO PERCENTUAL DO NÍVEL DE MATURIDADE...........18
FIGURA 2: NÍVEL DE MATURIDADE POR TIPO DE ORGANIZAÇÃO...................19
FIGURA 3: GRAU DE MATURIDADE POR CATEGORIA DE PROJETO.................19
FIGURA 4: GRAU DE MATURIDADE POR ÁREA DE ATUAÇÃO.............................20
FIGURA 5: NÍVEIS DE MATURIDADE NO MODELO PRADO-MMGP....................22
FIGURA 6: NÍVEIS DE MATURIDADE NO MODELO CMMI.....................................23
FIGURA 7: FLUXOGRAMA DO PROCESSO DE DECISÃO MAKE-OR-BUY..........61
15
1 INTRODUÇÃO
1.1 CONSIDERAÇÕES INICIAIS
O setor de tecnologia da informação (TI) tem sido um grande aliado das estratégias
das empresas através da apresentação de soluções tecnológicas de auxílio, acompanhamento e
análise tanto do desenvolvimento quanto da aplicação destas estratégias. Porém, ao mesmo
tempo em que se apresenta como aliado, tem sofrido uma grande pressão das altas gerências e
diretorias da empresa para que os projetos sejam desenvolvidos com a agilidade e
confiabilidade.
A TI, através de sistemas de softwares, se mostra como uma grande parceira em
diversas frentes, como na gestão da empresa através de softwares gerenciais, que integram
todos os dados e processos de uma organização, os chamados ERP (Enterprise Resource
Planning) ou SIGE (Sistemas Integrados de Gestão Empresarial); também no controle e
auxílio do relacionamento dos clientes, através do CRM (Customer Relationship
Management) ou GRC (Gestão de Relacionamento com o Cliente), ferramentas complexas
tidas como essenciais para a gestão e sobrevivência de uma empresa.
A TI também é uma grande parceira em outras frentes menos essenciais para o
funcionamento da empresa, porém muito importantes para a implantação das estratégias
necessárias a sua perpetuação. As empresas demandam diversos softwares para estas funções,
por exemplo podemos citar o BI (Business Intelligence), que auxilia no processo de coleta,
organização, análise, compartilhamento e monitoramento de informações que oferecem
suporte a gestão de negócios; ou os softwares para automação de força de vendas (AFV); as
soluções de controle de fluxo e aprovação de trabalho (workflow); até as ferramentas de
colaboração como email, intranet e extranet.
A Wasys, empresa que inspirou este trabalho, mantém seu foco comercial nesta
segunda frente, atuando como desenvolvedora e parceira do departamento de TI das
empresas, fornecendo consultoria, serviços e soluções de software. Neste contexto a Wasys
apresenta-se como uma empresa cujo core business é, essencialmente, baseado em projetos e,
assim, tem todas as implicações, necessidades e problemas que a gerência de projetos
apresenta.
16
No intuito de auxiliar no gerenciamento de projetos o presente trabalho apresenta
uma forma de medir e avaliar o nível de maturidade em gerenciamento de projeto. A partir do
nível atingido, é feita uma sugestão de boas práticas com o objetivo de aprimorar os processos
formais de gerenciamento projetos de software e, por consequência, tentar aprimorar o grau
de maturidade neste processo. O modelo de maturidade utilizado como referência neste
trabalho é o OPM3, proposto pelo PMI.
17
2 FUNDAMENTAÇÃO TEÓRICA
2.1 O QUE É MATURIDADE EM GERENCIAMENTO DE PROJETOS
O gerenciamento de projetos pode ser resumido como um processo que utiliza
conhecimentos, habilidades, ferramentas e técnicas junto às atividades do projeto com o
intuito de atingir os objetivos do mesmo e atender as suas demandas. Se conhecimento e
habilidades estão diretamente ligados às pessoas e as técnicas e ferramentas estão ligadas à
organização, tem-se por pressuposto que o gerenciamento de projetos exige esforço e
desenvolvimento corporativo e pessoal.
Apesar do gerenciamento de projetos depender muito das pessoas dentro da
organização, é a organização que deve promover a implantação ou aprimoramento do
processo de gerenciamento de projetos. A organização deve ser responsável pela seleção das
pessoas com as habilidades corretas, promover e difundir o conhecimento relacionado a
gerência de projetos e também escolher as técnicas e ferramentas que guiarão e auxiliaram
neste processo gerencial.
O grau de estruturação da organização no processo de gerenciamento de projetos é o
que denomina-se grau ou nível de maturidade organizacional em gerenciamento de projetos.
No mercado existem diversos modelos de maturidade, dentre os quais é possível destacar:
Organizational Project Management Maturity Model (OPM3) do PMI; o Kezner’s Project
Management Maturity Model (PMMM) do Dr. Kerzner; o Project Management Maturity
Model (PMMM) da PM Solutions; o PRINCE2 Maturity Model (P2MM); o Modelo Prado-
MMGP, criado por Darci Prado; e o Capability Maturity Model Integration (CMMI), voltado
para projetos de TI.
No ano de 2005, Darci Prado e Russel Archibald lançaram a 1ª Pesquisa Sobre
Maturidade em Gerenciamento de Projetos. A pesquisa, que foi realizada via Internet, teve
como objetivo tentar mapear a realidade das empresas brasileiras com relação à maturidade e
seus resultados habilitaram uma nova consciência e dimensão sobre o gerenciamento de
projetos no Brasil.
Em 2006 a pesquisa foi elaborada com 258 profissionais e seus resultados, que foram
classificados em algumas categorias, trazem importantes informações, conforme destacado a
seguir. A primeira classificação das informações é com relação ao grau de maturidade das
empresas que participaram da pesquisa. A maturidade média das organizações brasileiras que
18
responderam à pesquisa é de 2,42, um valor considerado médio-baixo. Na figura 1 temos o
gráfico de maturidade das organizações classificados em cinco níveis. Os níveis estão
explicados na tabela 1.
Figura 1: Distribuição percentual do nível de maturidade(Fonte: PRADO, Darci, ARCHIBALD, Russell. Pesquisa Sobre Maturidade em
Gerenciamento de Projetos, Relatório Anual – 2006. Disponível em www.maturityresearch.com. Acesso em 26/11/2008)
Tabela 1: Categorias de Nível de Maturidade.
(Fonte: PRADO, Darci, ARCHIBALD, Russell. Pesquisa Sobre Maturidade em Gerenciamento de Projetos, Relatório Anual – 2006. Disponível em
www.maturityresearch.com. Acesso em 26/11/2008)
Outra classificação que pode ser destacada é o nível de maturidade por tipo de
organização. A figura 2 mostra como se encontra esta situação.
19
Figura 2: Nível de Maturidade por Tipo de Organização(Fonte: PRADO, Darci, ARCHIBALD, Russell. Pesquisa Sobre Maturidade em
Gerenciamento de Projetos, Relatório Anual – 2006. Disponível em www.maturityresearch.com. Acesso em 26/11/2008)
Ainda é possível classificar o grau de maturidade de acordo com as categorias de
projetos do modelo de Archibald. A figura 3 mostra esta classificação.
Figura 3: Grau de Maturidade por Categoria de Projeto.(Fonte: PRADO, Darci, ARCHIBALD, Russell. Pesquisa Sobre Maturidade em
Gerenciamento de Projetos, Relatório Anual – 2006. Disponível em www.maturityresearch.com. Acesso em 26/11/2008)
Uma última e importante classificação é pelo ramo de atividade da empresa. Esta
classificação está na figura 4.
20
Figura 4: Grau de Maturidade por Área de Atuação(Fonte: PRADO, Darci, ARCHIBALD, Russell. Pesquisa Sobre Maturidade em
Gerenciamento de Projetos, Relatório Anual – 2006. Disponível em www.maturityresearch.com. Acesso em 26/11/2008)
A partir destes dados é possível concluir que as organizações ainda possuem um
longo caminho rumo a uma maior maturidade em gerenciamento de projetos. Os resultados
desta pesquisa mostram que 65,5% das organizações participantes estão no nível 1 e 2, ou
seja, ainda não implantaram padrões, métodos, estruturas ou sistemas de gerenciamento de
projetos que possa trazer resultados aos seus negócios. E somente 9% das organizações estão
em níveis 4 e 5, onde o domínio do processo de gerenciamento de projetos é alcançado.
2.2 MODELOS DE MATURIDADE EM GERENCIAMENTO DE PROJETOS
Os modelos de maturidade, além de mensurar o estágio da organização na habilidade
de gerenciar seus projetos, em geral permitem também classificar as empresas em categorias
de maturidade, possibilitando o benchmark entre empresas. E nestes modelos as empresas
podem formular seu planejamento estratégico de melhoria, pois a partir do conhecimento do
estágio atual é possível estabelecer um caminho para atingir outros níveis.
2.2.1 Modelo Prado - MMGP
Um modelo bastante difundido no mercado atual é o modelo Prado-MMGP,
publicado em 2002 e desenvolvido pelo professor Darci Prado, que permite avaliar e
classificar o grau de maturidade tanto setorial quanto da corporação. Tem bastante difusão no
21
mercado, principalmente por sua simplicidade, pois o questionário possui apenas 40 questões,
e também pela sua universalidade de aplicação em qualquer instituição e em todas categorias
de projetos. A partir da avaliação é possível classificar o grau de maturidade da organização
em cinco níveis possíveis: inicial, conhecido, padronizado, gerenciado e otimizado. Abaixo
segue a melhor descrição destes níveis:
Nível 1, ou “Inicial” (Ad hoc), está caracterizado pelo baixo nível de conhecimento
ou desconhecimento do assunto, a inexistência de metodologia e/ou modelos de
gerenciamento e o uso de intuição no gerenciamento dos projetos.
Nível 2, ou “Conhecido”, está caracterizado por investimentos em conhecimentos
(treinamento), início da criação de uma nova cultura, iniciativas dispersas e não padronizadas.
Nível 3, ou “Padronizado”, está caracterizado pelo início da existência de padrões,
mapeamento de processos, implementação de uma plataforma de governança (estrutura
organizacional), alinhamento estratégico, metodologias, informatização, competência e uso
rotineiro dos padrões pelos gerentes de projetos.
Nível 4, ou “Gerenciado”, é o nível onde padrões são utilizados, foram aperfeiçoados
e funcionam; as causas de erros comuns ou rotineiros identificadas e eliminadas; os
relacionamentos humanos são eficientes e existe uma alinhamento eficiente com negócios da
organização.
Nível 5, ou “Otimizado” , está caracterizado pela otimização de prazos, de custos, de
qualidade e dos processos de gerenciamento.
Os níveis foram escolhidos a partir das dimensões que afetam diretamente o sucesso
do gerenciamento dos projetos, sendo eles: conhecimentos de gerenciamento de projetos, uso
de metodologia, informatização, estrutura organizacional adequada, relacionamentos humanos
eficientes e alinhamento com os negócios da organização.
A figura 5 mostra um gráfico comparativo entre o nível de sucesso e o grau de
maturidade da empresa e em como as dimensões se ampliam à medida que a empresa se torna
mais madura.
22
Figura 5: Níveis de Maturidade no Modelo Prado-MMGP(Fonte: PRADO, Darci, ARCHIBALD, Russell. Pesquisa Sobre Maturidade em
Gerenciamento de Projetos, Relatório Anual – 2006. Disponível em www.maturityresearch.com. Acesso em 26/11/2008)
2.2.2 Modelo CMMI
Outro modelo de maturidade com bastante penetração de mercado é O Capability
Maturity Model Integration for Software (CMMI). O CMMI é um modelo desenvolvido pelo
Software Engineering Institute (SEI) que busca orientar as organizações de software na
implementação de melhorias contínuas em seu processo de desenvolvimento. O CMM guarda
algumas semelhanças com o modelo Prado-MMGP e também possui cinco níveis de
maturidade. Cada um destes níveis apresenta fundamentos sucessivos para a melhoria
contínua do processo.
O nível 1, chamado de “inicial”, é caracterizado como o estado caótico. Neste nível a
chance de sucesso e a garantia de qualidade do produto dependem de esforços individuais sem
qualquer nível de gerenciamento ou controle definidos explicitamente.
No nível 2, chamado de “repetível”, já existem processos básicos de gerenciamento
de projeto que permitem o acompanhamento de custo, cronograma e funcionalidade. É
repetível através dos procedimentos em outros processos similares.
O nível 3, chamado de “definido”, é caracterizado principalmente pela existência de
um processo de engenharia de software definido, documentado e padronizado. As atividades e
23
os entregáveis ou artefatos do processo de desenvolvimento de software são conhecidos,
compreendidos e documentados.
No nível 4, chamado de “gerenciado”, além das melhorias já implementadas no nível
3 também existe a preocupação, controle e medição da qualidade do processo e do produto.
Tanto o processo de software quanto os produtos são quantitativamente compreendidos e
controlados.
No nível 5, chamado de “otimizado”, há uma melhoria contínua dos processos. Este
nível permite avaliar e escolher com segurança novas tecnologias, técnicas, políticas de
treinamento e qualquer outra atividade relevante do processo, sempre buscando como
resultado um de produto de melhor qualidade.
A Figura 6 mostra a evolução do processo de desenvolvimento de software à medida
que se eleva no nível de maturidade.
Figura 6: Níveis de Maturidade no Modelo CMMI(fonte: FAGUNDES, Eduardo Mayer. Capability Maturity Model for Software. Disponível em
http://www.efagundes.com/artigos/CMM.htm. Acesso em 28/11/2008.)
2.2.3 O OPM3
Em 2004, o Project Management Institute (PMI) lançou o seu modelo de maturidade
Organizational Project Management Maturity Model (OPM3). Este modelo foi desenvolvido
com o apoio de mais de 800 voluntários com experiência em gerenciamento de projetos, tendo
por base 27 modelos de maturidade, incluindo 10 específicos sobre maturidade organizacional
e 9 da área de tecnologia de informação, incluindo o modelo CMMI.
24
O modelo OPM3 visa criar uma estrutura de melhoria contínua do ambiente de
gestão de projetos das organizações. Este objetivo é buscado através da recomendação de
“Boas Práticas”’ alinhadas com o PMBoK1, aceitas e utilizadas por empresas. Assim o PMI,
através do modelo OPM3, busca orientar as organizações na melhoria da gestão de projetos,
recomendando investimentos em treinamentos, disponibilização de novas ferramentas e
sistemas de controle de projeto, padronização de processos e documentação, entre outras
recomendações.
Dois conceitos importantes estão associados dentro do OPM3: as Boas Práticas e
Capacidades, e ambos estão associados a dois outros fatores chaves. Um é relacionando a
domínios de abrangência, sobre os quais se desenvolvem as indicações e recomendações de
amadurecimento organizacional. Os domínios mencionados no modelo OPM3 referem-se a
Projetos, Programas e Portfólio. O outro é associados aos estágios de melhoria contínua de
processos: “Standardize” onde têm-se processos estabelecidos, “Measure”, onde têm-se os
processos aplicados e avaliados, “Control”, onde os processos são monitorados e controlados
e “Continuous Improve”, onde os processos são aprimorados.
Para a aplicação do modelo OPM3 a orientação é a sequência de três elementos
chave:
• Conhecimento dos componentes do modelo de maturidade;
• Questionário de Auto-Avaliação do estágio de maturidade da organização;
• Processo De Melhoria contínua.
O elemento inicial do OPM3 é o conhecimento dos elementos básicos que o compõe:
boas práticas geralmente aceitas e experimentadas; capacidades ou pré-requisitos associados a
cada uma das boas práticas; resultados que comprovam a existência de uma ou mais
capacidades; indicadores chave de desempenho (KPIs), que possibilitam medir os resultados
atingidos; caminhos e ligações lógicas que agregam capacidades às boas práticas.
A fase seguinte é da auto avaliação, constituído por um questionário de escolhas
através do qual o usuário analisa e responde sobre a presença ou ausências de processos
formais no gerenciamento de projetos. As respostas dos questionários definem uma lista de
Boas Práticas que seriam recomendadas à organização.
A última etapa é que a organização faça uma análise da lista de Boas Práticas
recomendadas e verifique sua viabilidade e faça a sua priorização, e então e estabeleça um
1Project Management Body of Knowledge
25
plano composto pela melhor sequência de ações de melhoria em busca da elevação do grau de
maturidade.
O ciclo de melhoria contínua é a execução do plano de ação e pela reavaliação
periódica. Desta forma a aplicação do modelo OPM3 tem por objetivo aprimoramento real
dos processos organizacionais relativos ao gerenciamento de projetos buscando resultados
mais adequados e previsíveis.
Diferentemente dos demais modelos de maturidade, onde existe uma categorização
dos níveis de maturidade, normalmente constituído de 5 níveis, no modelo OPM3 não existe
este conceito. A princípio isto seria um ponto negativo neste modelo pois dificulta o
entendimento, benchmarking e o estabelecimento de metas mensuráveis e compromissos para
a melhoria da maturidade organizacional. Ao mesmo tempo esta ausência de categorias evita
que o nível de maturidade seja simplificado em uma nota final, onde uma grande maturidade
em uma determinada área poderia elevar a média e esconder resultados ruins em outras áreas.
A aplicação adequada e a melhoria contínua, através do OPM3, podem trazer resultados muito
positivos à organização.
2.2.4 Outros modelos
Existem ainda outros modelos de maturidade, que serão apenas citados, como o
Kezner’s Project Management Maturity Model (PMMM) do Dr. Kerzner, o Project
Management Maturity Model (PMMM) da PM Solutions, o PRINCE2 Maturity Model
(P2MM).
26
3 METODOLOGIA CIENTÍFICA
3.1 CONSIDERAÇÕES INICIAIS
A empresa objeto de estudo deste trabalho deseja implementar um programa de
melhorias no processo de gerência de projetos, porém sem burocratizar em excesso ou a ponto
de diminuir sua eficiência.
A equipe que desenvolveu este trabalho buscou o estudo e seleção do melhor modelo
de maturidade a ser aplicado e utilizado pela empresa. Após a escolha do modelo de
maturidade o esforço resumiu-se na otimização do questionário de avaliação para determinar
qual o grau de maturidade da empresa, pois tão importante quanto chegar a algum lugar é
necessário saber onde se está. Em seguida foram feitas considerações sobre processos que a
empresa poderia adotar, conforme as respostas que a empresa forneceu no questionário, para
que pudesse aumentar o seu grau de maturidade em gerenciamento de projetos.
3.2 A EMPRESA
Fundada em 1995 a Wasys é uma empresa integradora de soluções de TI.
Desenvolve soluções personalizadas usando as boas práticas de desenvolvimento do mercado,
baseada em tecnologias e metodologias amplamente aceitas. Além disso, a Wasys tem
diversas parcerias estratégicas que visam a distribuição de produtos de software e hardware
necessários à infra-estrutura da solução. Dentre as parcerias de destaque podem-se citar a
IBM, Microsoft e Claro.
Nos treze anos de existência a empresa passou por diversas evoluções e melhorias na
gerência de seus projetos, principalmente buscando a qualificação de seus gerentes de projeto.
3.3 O CONTEXTO
A empresa é basicamente voltada para desenvolvimento de projetos de
desenvolvimento de software ou prestação de serviços de informática. Seus contratos com
clientes possuem as principais características de projetos: são temporários, possuindo um
início e um fim definidos; são planejados, executados e controlados; entregam produtos,
serviços ou resultados exclusivos. A empresa em análise encontra os desafios e problemas
encontrados em outras empresas na implantação e desenvolvimento de projetos.
27
Os projetos de tecnologia da informação, em função das constantes mudanças que o
ambiente de negócios impõe, somado aos constantes avanços e evoluções tecnológicos, têm
que apresentar soluções flexíveis e ágeis. Não existe outro setor que tenha se desenvolvido e
evoluído tanto e em um ritmo tão devastador quanto o de tecnologia (IEEE, 2001).
A empresa vem mudando a sua forma de desenvolvimento e condução dos projetos:
anteriormente vinha de uma metodologia empírica e experimental, agora tem adotado formas
de condução formais baseadas em histórico e também através das metodologias de
gerenciamento de software existentes no mercado. Os processos e metodologias que são
usados para gerenciar projetos são extremamente importantes para aumentar a probabilidade
de sucesso, apesar de haver consciência de seus diretores que isto, por si só, não garante o
sucesso.
3.4 O OBJETIVO
A empresa deseja implementar um programa de melhorias no processo de gerência
de projetos com um objetivo de aumento gradual e constante do grau de maturidade. A
empresa espera, através deste programa, desenvolver uma metodologia de gerência de
projetos que permita um maior controle e proporcione uma menor chance de insucessos nos
seus projetos.
A empresa já possui um processo de desenvolvimento de software documentado e
alinhado com os objetivos de qualidade da empresa, assim o foco de amadurecimento será
basicamente em gerenciamento de projetos.
Existe, porém, uma grande preocupação da empresa em não burocratizar demais os
processos a fim de não perder sua agilidade e também não causar mudanças culturais muito
profundas que venham a trazer problemas motivacionais para a equipe.
3.5 O CENÁRIO ALVO
Para a elaboração do estudo do processo de avaliação de formas de melhorar o grau
de maturidade da empresa é necessário saber a contextualização, ou seja, quais são as
características médias dos projetos desenvolvidos pela empresa.
Atualmente não existe um processo formal de gerenciamento de projetos, sua
condução é feita por procedimentos não padronizados, intuição e experiência. Existem três
gerentes de projetos, conhecedores do PMBoK, que estão na empresa há seis anos, o que
28
proporciona uma boa integração da equipe, além de estarem sintonizados com os objetivos da
empresa.
Durante o ano de 2008 foram desenvolvidos e entregues 33 projetos caracterizados
em desenvolvimento de novos softwares e melhorias de softwares já existentes. De todos os
projetos executados, nenhum estourou o orçamento e apenas dois projetos (6% do total)
tiveram que ter o prazo de entrega renegociado, sendo que um deles teve atrasos na entrega
devido a problemas com o próprio cliente.
Vale destacar que suporte a softwares e manutenções não previstos (e em geral
emergenciais) surgiram entre os projetos, impactando no andamento deles. O volume de
projetos é relativamente constante, seja pelo próprio mercado, seja por negociações com os
clientes, o que não tem gerado uma demanda sazonal ou temporária de contratação de novos
recursos ou colaboradores.
Todo os projetos tiveram características de pequeno porte, demonstráveis pela
métrica da metodologia de desenvolvimento de software Rational Unified Process (RUP),
onde todos limitaram-se em 1.200 Use Case Points ou 20 homens/mês de esforço total. Outra
característica dos projetos é a sua curta duração, entre 45 a 90 dias desde o início do
desenvolvimento até a sua entrega, sendo em geral desenvolvido por equipes de até 5 pessoas.
Desta forma, cada gerente de projeto coordenou três projetos paralelamente, em
média.
Um ponto de destaque dentro da empresa é a integração da equipe de
desenvolvimento, onde a denominação correta a ser utilizada é "time", pois é bastante
comprometida com os projetos que atuam e preocupados com a satisfação do cliente. A
equipe também não tem um problema de Turn Over.
3.6 A ESCOLHA DO MODELO DE MATURIDADE
A escolha do modelo de maturidade foi o Organizational Project Management
Maturity Model (OPM3), do PMI. A grande motivação da escolha foi o fato de ser um modelo
moderno, com grande alinhamento com o PMI e seu PMBoK, pois a empresa já iniciou o
treinamento e difusão do conhecimento do PMBoK entre os gerentes de projeto. Como a
empresa já possui um processo de desenvolvimento de software documentado e alinhado com
os objetivos de qualidade da empresa, a escolha de um modelo de maturidade específico para
a área de tecnologia, como o CMMI, foi descartado.
29
Sendo o objetivo principal da empresa melhorar o seu processo de gerenciamento de
software para se tornar mais eficiente e competitiva, não desejando, neste momento, fazer
comparações de benchmarking com outras empresas e também não deseja obter certificações
em modelos específicos de maturidade, o modelo OPM3 mostrou-se suficiente. O modelo
OPM3 permite obter uma auto-avaliação do grau de maturidade sem classificar em níveis pré-
determinados, e com uma avaliação de maturidade que pode ser elevada à medida que o plano
de melhoria é colocado em prática.
Além de fornecer notas no processo de auto-avaliação, o modelo OPM3, a partir das
respostas das perguntas, seleciona uma sugestão de boas práticas a serem adotadas pela
empresa, alinhadas com o PMI e com sua utilização e aceitação por organizações e gerentes
de projetos. Assim, o OPM3 mais uma vez mostrou-se bastante interessante, pois além da
avaliação fornece insumos básicos para se montar um plano de melhorias, de acordo com as
intenções da empresa.
3.7 A ADEQUAÇÃO DO MODELO OPM3
O modelo OPM3 possui aplicação para empresas de todos os portes, e não só para
projetos, mas também para programa e portfólio. Assim, para a aplicação em pequenas
empresas que desenvolvem projetos de curta duração e de pequeno porte, fez-se necessária
uma adequação do questionário e das sugestões de boas práticas.
O processo de adequação do OPM3 seguiu as seguintes linhas:
a) O foco da empresa é em projetos para empresas contratantes, por isso:
• Boas Práticas referentes a priorização de projetos foram retirados;
• Boas Práticas referentes a Gerenciamento de Programa e Portfólio, inter-
relacionamento entre projetos foram retirados.
b) A equipe de gerenciamento e desenvolvimento de projetos é praticamente fixa, havendo
pouca variação dos membros da equipe (turnover) com o início ou término de projetos, não
sendo a contratação ou montagem de equipe realizada a cada projeto, por isso:
• Boas Práticas referentes a desenvolvimento de equipes foram retirados;
• Boas Práticas referentes a contratação de equipe (Staff) foram omitidos;
• O conjunto de Boas Práticas de gerenciamento de RH foi simplificado.
c) A maioria dos projetos desenvolvidos é de curta duração (3-5 meses), com equipes de 3 a 7
pessoas, e de mesma natureza, havendo muitas características comuns entre os projetos. A
30
maioria do faturamento vem de um portfólio restrito de clientes, com os quais a empresa já
está adaptada (tecnicamente, metodologicamente e relacionalmente), por isso:
• Boas Práticas referentes a planejamento organizacional de projeto foram omitidos;
• O conjunto de Boas Práticas referentes a gerenciamento de comunicação foi
simplificado, focando na comunicação com o cliente, e menos na comunicação
interna;
• O conjunto de Boas Práticas para iniciação, gerenciamento de escopo, custo e tempo
foi simplificado;
• O conjunto de Boas Práticas para gerenciamento de riscos foi simplificado;
• O conjunto de Boas Práticas para definição e utilização de métricas para controle de
todos os processos foi simplificado.
d) A natureza dos projetos raramente demanda aquisições. No processo de aquisição, a
empresa quase sempre faz papel de fornecedora, por isso o conjunto de Boas Práticas
referentes a gerenciamento de aquisições foi simplificado.
e) Os processos de garantia e controle de qualidade, e formalização de entregas seguem um
mesmo padrão aplicado a quase a totalidade dos projetos, ou são definidos pelo próprio
cliente, caso o mesmo possua metodologia própria de desenvolvimento de sistemas, por
isso:
• o conjunto de Boas Práticas de gerenciamento de qualidade foi simplificado;
• o conjunto de Boas Práticas de verificação de escopo foi simplificado.
f) Os objetivos dos projetos se limitam a: lucratividade, conquista de novo mercado e
conquista de espaço em cliente. Por isso o conjunto de Boas Práticas referentes a definição
e acompanhamento de objetivos pelos stakeholders foram minimizados.
3.8 O MODELO SUGERIDO
O modelo OPM3 adequado à aplicação na empresa foi elaborado pelos autores do
presente trabalho. No apêndice I tem-se o questionário a ser aplicado na empresa, com as
perguntas selecionadas e adaptadas pelos autores a partir das perguntas encontradas no
OPM3. Para as perguntas devem ser fornecidas respostas conforme a frequência de ocorrência
da situação na empresa. A tabela 2 ilustra os pesos que foram atribuídos às frequências de
ocorrência na empresa.
31
Tabela 2: Relação de pesos versus utilização
Peso
Frequência de
verificação
0 Nunca
1 Raramente
2 Algumas vezes
3 Metade das vezes
4 Várias vezes
5 Sempre
Fonte: os próprios autores
Todas as perguntas foram relacionadas a áreas de conhecimento do PMBoK, sendo
que algumas das perguntas se referem à cultura organizacional da empresa ou a mais de uma
área de conhecimento. Para estas os autores indicaram um novo código, conforme
demonstrado na tabela 3.
Tabela 3: Relação das Áreas de Conhecimento
Área de
Conhecimento Descrição
4 Integração
5 Escopo
6 Tempo
7 Custo
8 Qualidade
9 RH
10 Comunicação
11 Riscos
12 Aquisições
99 Cultura da empresa – Várias
Fonte: os próprios autores
32
Também houve um relacionamento entre as perguntas e a seu estágio de melhoria
(conforme explicado no item 2.2.3 - O OPM3, páginas 23 e seguintes). Esta relação é
mostrada na tabela 4.
Tabela 4: Relação das Estágios
Estágios Descrição
1 Padronizar
2 Medir
3 Controlar
4 Aprimorar
5
Cultura da empresa –
Várias
Fonte: os próprios autores.
No apêndice II tem-se a lista de boas práticas, selecionadas pelos autores a partir das
boas práticas apresentadas pelo OPM3, com as respectivas áreas de conhecimento e estágio de
maturidade. No apêndice III tem-se a correspondência numérica entre as perguntas e as boas
práticas e no apêndice IV tem-se a lista de perguntas e as boas práticas correspondentes, de
uma forma mais descritiva.
Todo o processo de avaliação foi elaborado de uma forma estruturada, o que permite
que seja facilmente desenvolvido um software específico para aplicação do questionário do
presente trabalho, o que permitiria à empresa constantemente reaplicar esta auto-avaliação e
determinar qual progresso houve na evolução em seu grau de maturidade. O sistema também
poderá fornecer de forma mais simples e rápida (do que a consulta a tabelas impressas) quais
as boas práticas que deveriam ser implantadas na empresa.
33
4 ANÁLISE DOS RESULTADOS
4.1 CONSIDERAÇÕES INICIAIS
O formulário de questionário foi respondido em conjunto pelos três gerentes de
projetos da empresa, o que possibilitou uma maior veracidade e reflexo da visão de cada um
sobre seus projetos e sobre todos os projetos da empresa. No apêndice VI reproduzimos o
questionário respondido.
4.2 RESULTADOS
Os resultados obtidos demostraram que a empresa possui uma baixa maturidade em
gerenciamento de projetos, como já era esperado pelas informações fornecidas antes da
avaliação. Os resultados obtidos por área de conhecimento estão na tabela 5, onde é possível
verificar que existe uma relativa preocupação da empresa em algumas áreas de conhecimento.
A atenção principal da empresa ocorre nas áreas em que há um peso maior em projetos, como
escopo e tempo, porém faltam esforços em outras áreas importantes, como custos,
comunicação e riscos, que poderiam ser um diferencial competitivo no mercado.
Tabela 5: Resultados por Área de Conhecimento
Área de conhecimento Nota
Integração 21,67%
Escopo 23,33%
Tempo 29,09%
Custo 7,69%
Qualidade 12,50%
RH 0,00%
Comunicação 0,00%
Riscos 0,00%
Aquisições 11,43%
Estrutura da Empresa 27,73%
34
Média Geral 13,34%
Fonte: os próprios autores
Outra forma de interpretação dos resultados é separando por estágios de maturidade,
conforme demonstrado na Tabela 6. Verifica-se que a preocupação da empresa com seu grau
de maturidade é coerente, pois a formalização de processos é quase inexistente.
Tabela 6: Resultados dos Estágios de Maturidade
Resultado por domínio
Padronizar 0,83%
Medir 31,67%
Controlar 17,06%
Aprimorar 12,50%
Estrutura da Empresa 39,00%
Fonte: os autores
Os autores do presente trabalho destacam que os resultados mostrados nestas duas
tabelas comprovam que houve bastante coerência no trabalho feito. Os resultados por área de
conhecimento mostram que houve correspondência entre as informações que eram conhecidas
sobre a empresa e as respostas dadas ao questionário. Já as respostas dos estágios de
maturidade comprovaram que a empresa aplica apenas seus conhecimentos empíricos, mas
não possui formalidades em seus projetos, também conforme havia sido informado no perfil
da empresa.
Apesar do relativo sucesso nos projetos desenvolvidos por ela, vale destacar que ela
poderá se beneficiar com a adoção do modelo de maturidade aqui proposto, pois permitirá
avaliar e elaborar um plano estratégico para melhoria dos processos de gerenciamento de
projetos. Um processo de gerenciamento de projetos é uma garantia a mais da continuidade de
sucesso dos projetos, assim como um diferencial competitivo frente aos seus concorrentes.
35
4.3 DISCUSSÃO DOS RESULTADOS
Analisando os resultados obtidos a partir da aplicação do questionário, percebe-se
que a empresa possui diversos pontos onde é possível buscar um aumento de maturidade em
gerenciamento de projetos. Pelo sucesso obtido pela empresa ao longo destes anos de
existência, deduz-se que há um conhecimento sobre a condução de projetos, mas este
conhecimento está limitado à prática diária de tarefas. As melhorias que serão propostas a
seguir auxiliarão a empresa a documentar o conhecimento de toda a sua equipe facilitando a
difusão do conhecimento dos gerentes de projeto, fornecendo um histórico de referência para
consultas e análises, permitindo uma comparação entre os seus projetos e, por fim, permitindo
que a empresa delimite os seus pontos fracos e assim possa promover a sua correção.
As sugestões foram divididas conforme as áreas de conhecimento do PMBoK,
buscando-se abranger todos os estágios de maturidade.
4.3.1 Integração
Os processos de gerenciamento de integração, como o próprio nome diz, são os
responsáveis pela integração das demais áreas de conhecimento e os recursos envolvidos no
projeto. O PMBoK recomenda os seguintes processos na integração do gerenciamento de
projetos:
• Desenvolver o termo de abertura do projeto – desenvolvimento do termo de abertura
do projeto que autoriza formalmente um projeto ou uma fase do projeto.
• Desenvolver a declaração do escopo preliminar do projeto – desenvolvimento da
declaração do escopo preliminar do projeto que fornece uma descrição de alto nível do
escopo.
• Desenvolver o plano de gerenciamento do projeto – documentação das ações
necessárias para definir, preparar, integrar e coordenar todos os planos auxiliares em
um plano de gerenciamento do projeto.
• Orientar e gerenciar a execução do projeto – execução do trabalho definido no plano
de gerenciamento do projeto para atingir os requisitos do projeto definidos na
declaração do escopo do projeto.
• Monitorar e controlar o trabalho do projeto – monitoramento e controle dos processos
usados para iniciar, planejar, executar e encerrar um projeto para atender aos objetivos
de desempenho definidos no plano de gerenciamento do projeto
36
Pela natureza dos negócios da empresa ela pode ser classificada como “Fábrica de
Software”, ou seja, o negócio principal é o desenvolvimento de projetos para clientes. Desta
forma o processo produtivo da empresa são os projetos e o desenvolvimento dos mesmos
exige apenas o envolvimento de membros do departamento de desenvolvimento, que
hierarquicamente estão sobre a mesma diretoria. Em geral os projetos são desenvolvidos por
pessoas focadas apenas no desenvolvimento do mesmo, ou seja, sem outras atividades
rotineiras ou atividades de outros projetos. Desta forma o trabalho do gerente de projetos (GP)
é simplificado nas atividades de gerenciamento de integração, possuindo uma equipe que, por
definição, estará comprometida com o projeto e também não exigindo do GP habilidades
políticas especiais ou necessidade de um Sponsor forte.
Uma das sugestões para a empresa, quanto a área de integração, é que haja um maior
cuidado com a iniciação dos projetos. A etapa de iniciação do projeto envolve atividades do
gerenciamento de integração, que seriam o desenvolvimento do Termo de Abertura do
Projeto, ou project charter, e a Declaração Preliminar do Escopo. Conforme explanado
anteriormente em relação a características dos projetos e da empresa, a recomendação é a
junção dos dois documentos e nominá-lo de Termo de Abertura do Projeto. A função deste
documento é a necessidade do registro formal do início do projeto, da alocação do gerente de
projetos, da equipe envolvida e do escopo preliminar. Recomenda-se que este documento seja
compartilhado com toda equipe envolvida, principalmente com o analista responsável, para
que todos estejam cientes do escopo macro do projeto. O modelo sugerido para este
documento encontra-se no item 8.5 (Error: Reference source not found: Error: Reference
source not found, pag. 144) e deve ser elaborado pelo gerente de projetos a partir das
informações contidas na proposta aceita pelo cliente, assim como informações fornecidas pelo
departamento comercial.
Uma segunda sugestão é que a empresa passe a adotar um plano de gerenciamento
do projeto. O plano de gerenciamento de projeto é o plano global com as instruções para o
gerente e equipe identificarem e formalizarem como desenvolver o produto do projeto. No seu
conteúdo estão as ações necessárias de definição e integração dos diversos planos de
gerenciamento das outras áreas de conhecimento. Também traz como o projeto deve ser
orientado e monitorado, assim como os processos de gerenciamento de mudanças. A
elaboração do plano é de responsabilidade do gerente do projeto, porém deve ser elaborada
em colaboração com os membros da equipe. Para isto podem ser utilizados com entradas os
37
seguintes documentos: Termo de Abertura do Projeto, Orçamento (Linha Base de Custos),
Cronograma (Linha Base de Tempo), e uma Linha Base de Escopo). Através da ligação das
etapas destes diversos documentos, poderá ser criado um Plano de gerenciamento do projeto.
O modelo de plano está descrito no item 8.5 (Error: Reference source not found: Error:
Reference source not found, pag. 145) e deverá ser utilizado pela organização.
Outra sugestão é que haja uma maior orientação dos Gerentes de Projeto da empresa
quanto aos papéis de orientação que são esperados. Mesmo sendo o perfil da empresa possuir
seus gerentes de projeto já familiarizados com as práticas do PMBoK, parece ser interessante
um treinamento sobre as suas responsabilidades enquanto orientadores. O processo de
desenvolvimento de software on demand, em geral, segue alguns passos ou etapas comuns a
todos os projetos, conforme a seguir: levantamento de requisitos, documentação dos
requisitos, análise do sistema a partir dos requisitos, desenvolvimento do sistema a partir da
análise, testes das funcionalidades e entrega do sistema. Para cada uma destas etapas o gerente
de projetos precisa efetuar a orientação da equipe no desenvolvimento das atividades.
Apesar do processo de orientação e controle do projeto depender muito das
características do gerente de projeto de pró-ação, liderança, capacidades, conhecimentos e
diversas outras, algumas orientações básicas são necessárias. Para sua execução precisam dos
seguintes documentos como entrada: Declaração preliminar do escopo, Orçamento (Linha
Base de Custos), Cronograma (Linha Base de Tempo), WBS e Dicionário (Linha Base de
Escopo). As orientações básicas que estão descritas abaixo são as mínimas necessárias:
• Orientação Inicial: para as primeiras atividades do projeto, ou seja, levantamento de
requisitos, apenas um analista ou desenvolvedor principal está envolvido. O gerente de
projeto fazer a orientação para deixar o responsável a par dos objetivos e
principalmente do escopo preliminar do projeto. Também são recomendadas as
orientações necessárias sobre as características do cliente.
• Orientação sobre os requisitos: nas atividades de documentação dos requisitos, análise
do sistema a partir dos requisitos, apenas um analista ou desenvolvedor principal está
envolvido. O gerente deve orientar o responsável para que verifique se os requisitos
levantados estão de acordo com o escopo preliminar e para que reporte todos os
pontos discordantes para que sejam efetuadas as ações necessárias para negociação de
escopo com o cliente.
38
• Orientação inicial da equipe: O gerente de projeto deve orientar toda a equipe de
desenvolvimento no início do processo de desenvolvimento. Esta orientação torna-se
necessária para deixar os responsáveis a par dos objetivos do projeto. Deve ser
dedicada atenção especial ao escopo e cronograma do projeto, destacando os papeis de
cada integrante, suas responsabilidades e os prazos e metas a cumprir.
• Orientação constante da equipe: O gerente de projeto deve orientar toda a equipe de
desenvolvimento durante o desenvolvimento do projeto. Este processo é necessário
para manter o foco da equipe nos objetivos do projeto e dentro do planejamento
inicial.
Quanto à execução do projeto, o gerente deverá executar diversas atividades no
transcorrer do desenvolvimento do projeto para garantir que o plano esteja sendo cumprido e
também que possa ter subsídios para tomar decisões necessárias para que os objetivos do
projeto sejam atingidos. As atividades de controle do projeto que devem ser executadas pelo
gerente de projetos são:
• Processo de aceite de Funcionalidades do Sistema: conforme descrito abaixo no item
de verificação de escopo (pag. 43), o gerente de projeto deve ser responsável pelo
controle do aceite dos entregáveis junto ao cliente.
• Controles dos Processos de Planejamento, Definição e Verificação de Escopo:
conforme descrito abaixo no item de verificação de escopo (pag. 43), o gerente de
projeto deve ser responsável pelo controle do escopo e das atividades executadas pela
equipe.
• Processos de controle de custos: conforme descrito no item 4.3.4, no Error: Reference
source not found (pag. 48) o gerente de projeto deve coletar as informações de
progresso do projeto e efetuar os cálculos do EVA e dos relatórios de desempenho.
• Processos de controle do cronograma: conforme será mencionado no item 4.3.3
(Tempo, pág. 45), a empresa possui já um certo controle sobre o tempo de suas
atividades, sendo necessário pequenos ajustes apenas para que haja informações
históricas adequadas para consultas durante a elaboração de novos projetos;
• Processos de controle da qualidade: serão explicados adiante, no item 4.3.5,
Qualidade, pag. 51;
• Processos de controle dos riscos: conforme será explicado no item 4.3.8 (Riscos, pag.
58), a empresa não possui qualquer controle de riscos, sendo uma grande oportunidade
39
de ganhos de competitividade se um mínimo de processo de gerenciamento de riscos
for implantado;
• Processos de controle integrado de mudanças: conforme será descrito abaixo, o
gerente de projeto deve receber, documentar, analisar e repassar todas as solicitações
de mudanças efetuadas.
• Processos de encerramento do projeto: conforme será descrito abaixo (pag. 40), o
gerente de projeto deve ser responsável por todas atividades de controle da
formalização do encerramento do projeto, liberação de recursos, encerramento do
projeto e documentação das lições aprendidas.
Há também recomendação que o Gerente de Projetos tenha um cuidado especial com
o controle de mudanças. As mudanças do projeto são uma certeza durante a execução do
mesmo e que podem ocorrer por diversos fatores desde a adequação a novas necessidades até
o desconhecimento de todas das necessidades pelo cliente. As mudanças, dependendo da
natureza, podem incorrer em replanejamentos ou retrabalhos. Em projetos de software existe
ainda o agravante da intangibilidade, ou seja, não é algo material ou palpável e novas
necessidades são descobertas após a entrega da primeira versão ou release do sistema. As
mudanças podem surgir ainda de defeitos ou discrepâncias encontradas durante execução do
projeto, na etapa de testes ou homologação do sistema. Todas as mudanças solicitadas devem
ser registradas e documentadas, sejam elas executadas ou não, a fim de que não ocorra uma
nova análise em caso de uma nova solicitação para a mesma mudança. O processo de controle
de mudanças está abaixo descrito. Para um controle de mudanças que seja fácil de
implementar na empresa, sugere-se que sejam utilizados os seguintes documentos como
entrada: Plano de gerenciamento de projeto, Mudanças solicitadas, Informações sobre o
desempenho do trabalho, Reparos recomendados de defeitos, Entregas devidas.
Um procedimento possível para controle de mudanças é o seguinte:
1. Analisar a viabilidade da mudança. Verificar se a solicitação da mudança é procedente
e é viável de ser executada, pois podem haver impedimentos técnicos. Caso não seja
viável o processo de avaliação finaliza. Deve-se envolver a equipe técnica na
avaliação;
2. Analisar a necessidade e justificativa da mudança. Caso a alteração seja viável é
necessário avaliar se ela é necessária e justificável. Solicitações que provocam
alterações nos objetivos do processo devem ser analisadas com cuidado. Caso não seja
40
necessária e nem justificável o processo de avaliação finaliza. Deve-se envolver o
cliente na avaliação, se necessário.
3. Avaliar o impacto. Caso a alteração seja necessária e justificável é necessário avaliar
os impactos que esta alteração provocará inicialmente no escopo, custo e tempo do
projeto. Deve ser também analisado com atenção para os impactos nos riscos do
projeto, pois podem introduzir novos riscos, assim como aumentar a probabilidade e
impacto dos já existentes.
4. Documentar e repassar a análise e impactos ao cliente. Após fazer a análise e ter em
mãos os impactos das alterações é necessário repassá-las ao cliente para sua
apreciação e aprovação ou não. Todas as mudanças aprovadas precisam ter um aceite
formal do cliente.
5. Alterar os planos do projeto. Com a aprovação pelo cliente é necessário alterar os
planos do projeto e repassar as alterações para a equipe e responsáveis.
Com este controle, haverão as seguintes saídas:
• Solicitações de mudanças aprovadas e rejeitadas. As solicitações de mudanças devem
utilizar o modelo descrito no item 8.5 (Error: Reference source not found: Error:
Reference source not found, pag.146);
• Plano de gerenciamento do projeto atualizado;
• Reparo do defeito validado
Por fim, há recomendação que a empresa formalize também os procedimentos para
encerramento de projetos. O processo de encerramento do projeto é necessário para formalizar
que o projeto foi executado a contento sendo necessário liberar recursos alocados e finalizar
contratos. Em caso de projetos desenvolvidos em fases, o processo de encerramento deve
ocorrer a cada fase finalizada. O processo de encerramento do projeto ainda precisa contar
com o aceite formal do cliente da entrega do projeto ou fase do projeto. Uma sugestão para
sua execução é a seguinte:
1. Finalizar todos os itens do sistema após todas as melhorias e alterações solicitadas na
fase de homologação. Fechar versão do sistema e atualizar documentação de análise;
2. Receber o aceite formal da finalização da homologação e início da garantia. Seguir o
processo recomendado pelo Sistema da Qualidade;
3. Encerrar contratos com terceiros. Seguir o processo recomendado pelo Sistema da
Qualidade;
41
4. Registrar as lições aprendidas. Desta forma, além de haver encerramento formal de
todos os contratos, haverá um documento de lições aprendidas. Os registros de lições
aprendidas devem utilizar o modelo descrito no item 8.5 (Error: Reference source not
found: Error: Reference source not found, pag. 148).
No apêndice V são colocados modelos de documentos para as sugestões apresentadas
para o controle de integração.
4.3.2 Escopo
Na área de escopo observa-se que a empresa, embora utilize um processo consistente
para planejar o escopo, não possui um processo padronizado para sua definição. Isto
provavelmente leva a dificuldades em monitorar e controlar os processos referentes a escopo,
mapear objetivos do projeto para os itens do escopo, identificar oportunidades de melhoria e
implementá-las.
Padronizando o processo de definição de escopo, e estabelecendo indicadores e
atividades de controle fundamentadas nesta definição, a empresa poderá ter um salto
qualitativo considerável na sua maturidade referente a esta área de conhecimento.
Como os projetos em questão são de software, grande parte do escopo do projeto
consiste nos seus requisitos de software. Esse aspecto deve ser levado em consideração para
devidamente interligar as boas práticas recomendadas do PMBoK com a realidade de um
processo de engenharia de software.
A primeira sugestão é que a empresa possua um processo de planejamento e
definição do escopo do projeto. Para isto a empresa poderá usar, como insumo, o Project
Charter, onde o escopo preliminar do projeto estará descrito, com as características do
produto, restrições e necessidades específicas da organização e do cliente. Os seguintes passos
podem ser usados neste processo:
1. Criar WBS e dicionário inicial, contemplando o que está especificado no Project
Charter (inclusive a visão básica do produto a desenvolver) mais os artefatos de
gerenciamento conforme metodologia vigente na empresa. Recomenda-se utilização
da forma gráfica da WBS, pois possibilita melhor visualização e entendimento. Para
geração da WBS, pode-se utilizar uma ferramenta de apoio, como o WBS Chart Pro,
da Critical Tools Corporation, ou o Microsoft Visio;
42
2. Realizar sucessivas reuniões entre os Analistas e o cliente, segundo a técnica FAST
(Facilitated Application Specification Techniques), na qual os requisitos serão
solicitados e documentados em formato rascunho em uma série de cenários;
3. Tendo como entrada os cenários documentados nas reuniões FAST, os analistas
traduzem o entendimento dos mesmos através de um conjunto de use cases, conforme
padrão UML, subordinando os cenários a um ou mais use cases definidos em uma
iteração anterior, ou definindo novos use cases. A documentação de use cases é feita
conforme template já em uso pela empresa. Neste processo podem ser identificados
outros itens não previstos no escopo geral do projeto (fora o escopo do produto), como
riscos, necessidade de treinamento, aquisições, testes diferenciados, entre outros;
4. Realiza os passos 2 e 3 em iterações até que a lista de use cases e seus detalhamentos
possibilitem:
• Que o cliente visualize nos use cases todas as funcionalidades que espera do
sistema;
• Que os Analistas estimem o esforço para desenvolvimento das funcionalidades,
provendo entradas para os planejamentos de tempo, custo, RH e outros;
5. Atualizar a WBS com o resultado do levantamento de requisitos, incluindo o escopo
do produto e outros itens do escopo do projeto que tenham sido identificados. O
dicionário da WBS deve ser atualizado, e os pacotes de trabalho referentes aos use
cases devem fazer apontamentos para os documentos de use case correspondentes.
Caso necessário, itens de arquitetura de software adicional devem ser especificados
como pacotes de trabalho abaixo dos respectivos use cases.
6. Especificar os casos de teste de aceitação para cada use cases, os quais servirão como
critério de aceitação dos mesmos. Os casos de teste podem ser divididos em casos de
teste funcionais e casos de teste operacionais, sendo estes últimos para testes de
performance, segurança, estabilidade, entre outros critérios, conforme a complexidade
e criticidade do software;
7. Obter do cliente a formalização do aceite da definição do escopo. Nesta formalização,
o cliente concorda que a WBS, o dicionário e os documentos de use cases representam
todas as funcionalidades desejadas do sistema a ser construído e todas os entregáveis
do projeto como um todo, e que alterações neste escopo estarão sujeitas às regras
43
definidas no controle integrado de mudanças. Neste aceite, o cliente deve formalizar
estar de acordo também com os critérios de aceitação dos entregáveis.
Seguindo-se estes passos, serão produzidos os seguintes documentos: WBS,
dicionário da WBS, documentação de Use Cases, documentação de casos de teste e aceite
formal do cliente (consistente da assinatura dos entregáveis previamente listados).
Uma segunda sugestão é que a empresa formalize o processo de verificação do
escopo. Para isto utilizará os documentos gerados pelo processo de planejamento e definição
do escopo e seguirá os seguintes passos:
1. A equipe libera o sistema (ou parte dele) para que cliente realize os testes definidos na
documentação de casos de teste para o(s) use case(s) em questão;
2. O cliente realiza os testes conforme documentação, reportando irregularidades
encontradas com relação à documentação de casos de teste ou à documentação de
requisitos (use cases);
3. Os defeitos encontrados são contabilizados e reportados para a equipe;
4. A equipe realiza as correções aplicáveis e libera novamente o sistema para testes do
cliente;
5. Os passos 2, 3 e 4 são repetidos até que todos os casos de teste tenham sido testados
com sucesso pelo cliente;
6. Caso o cliente, ao realizar os testes, verifique que o comportamento especificado não
atende suas expectativas, deve solicitar as alterações desejadas através de um change
request (conforme descrito acima, na recomendação de controle de mudanças, pag.
39);
7. Encerrados os testes com sucesso, o cliente deve assinar um formulário de aceitação
para o(s) use case(s) alvo do teste.
Para outros entregáveisa empresa poderá adotar os seguintes passos:
1. A equipe libera o entregável para inspeção do cliente;
2. O cliente realiza inspeção conforme definido pelo item de critérios de aceitação
descrito no dicionário da WBS;
3. Os defeitos encontrados são contabilizados e reportados para a equipe;
4. A equipe realiza as correções aplicáveis e libera novamente o entregável para inspeção
do cliente;
44
5. Os passos 2, 3 e 4 são repetidos até que os critérios de aceitação tenham sido
atendidos, conforme entendimento comum entre cliente e equipe de projeto;
6. Caso o cliente, ao realizar a inspeção, verifique que o entregável, mesmo atendendo
aos critérios pré-definidos, não atende suas expectativas, deve solicitar as alterações
desejadas através de um change request (vide o processo de controle integrado de
mudanças comentado acima, pag. 39);
7. Encerradas as inspeções, o cliente deve assinar um formulário de aceitação para os
entregáveis em questão.
Desta forma serão obtidos os seguintes itens: formulário de aceite assinado pelo
cliente para os itens verificados / testados e change request.
Sugere-se, com base nestes dois processos, que a empresa adote as seguintes
métricas para acompanhamento de seus projetos:
• Percentual de esforço gasto nestas fases com relação ao esforço total do projeto: a
partir da estimativa inicial de esforço do projeto, utilizada para fechar o contrato com
o cliente (o que é feito antes da etapa de planejamento detalhado), pode-se determinar
qual a porcentagem de tempo ou esforço/custo que está sendo gasto com os referidos
processos, comparado com o esforço/tempo total do projeto. Isso possibilitará a
criação de uma base histórica que possibilitará estimativas mais realistas para estas
atividades em projetos futuros. Também possibilitará saber se um projeto está
gastando mais tempo que o normal com algum destes processos, possivelmente
trazendo a tona um problema de projeto que sem esta medição ficaria oculto por mais
tempo, podendo gerar mais prejuízos;
• Relação da Quantidade de Change Requests com o total de Use Case Points
(Complexidade/Tamanho) do Projeto: a medição periódica deste indicador também
possibilitará a geração de histórico e a identificação precoce de problemas,
comparando-se o mesmo com o histórico existente. Além disso, um valor alto para
este indicador apontará prováveis problemas com o processo de definição do escopo;
• Relação da Quantidade de Erros encontrados ao executar os test cases com o total de
Use Case Points (Complexidade/Tamanho) do Projeto: um valor alto deste indicador
apontará prováveis problemas com os processos de controle e garantia de qualidade,
ou ainda do processo de planejamento da verificação do escopo.
45
Como última recomendação desta área, sugere-se que o controle dos processos de
planejamento, definição e verificação de escopo atentem aos seguintes itens:
• Obtenção de aceite formal do cliente para a definição do escopo do projeto antes do
início das atividades de design e construção. Antes deste aceite, todos os documentos
são assinados pelo analista responsável, o qual deverá garantir a consistência dos
mesmos antes de disponibilizar para o cliente; e
• Verificação quinzenal dos indicadores relacionados nas métricas acima.
No apendice V são colocados modelos de documentos para as sugestões apresentadas
para o controle de escopo.
4.3.3 Tempo
Na área de tempo verifica-se que a empresa possui um bom atendimento aos prazos
acordados com os clientes, conforme informações obtidas pelo levantamento do cenário de
empresa. Há ausência, entretanto, de alguns outros controles que poderiam auxiliar a empresa
na execução de seus projetos:
• ausência de métricas para o controle de tempo;
• não há um controle sobre a execução do planejamento executado;
• possui controle de mudanças de calendário, mas não o aplica durante os projetos;
• não há controle sobre os impactos que os riscos poderão gerar no cronograma de
atividades;
• não há histório que permita comparar o que foi planejado com o que foi efetivamente
executado.
Uma primeira sugestão para a empresa é que ela passe a adotar métricas para o
controle da duração das atividades e, assim, possa verificar o andamento de seus projetos e
fazer estimativas sobre suas próximas atividades. Como será explicado em um item seguinte
(item 4.3.4, no Error: Reference source not found, pag. 48) o uso do earned value analysis
(EVA) poderá auxiliar a empresa a controlar seus cronogramas ao mesmo tempo que controla
seus custos.
Outra recomendação é que a empresa implemente efetivamente o seu controle de
mudanças de calendário. Certamente o impacto da implementação desta atividade será
pequeno, já que a empresa trabalha sempre com equipes pequenas e projetos de curta duração.
Os ganhos serão bastante visíveis, entretanto, quando esta prática evitar que o fato de um
46
analista responsável por um determinado projeto apresentar algum contratempo (ou mesmo
deixar a empresa) e descobrir-se que o cronograma que está documentado não corresponde à
realidade do projeto, muito menos ao que foi re-negociado com o cliente.
O questionário também mostrou que não há preocupação da empresa com a análise
dos riscos passíveis de ocorrência no projeto. Como estes riscos poderão, eventualmente,
impactar em cronograma, sugere-se que a empresa atente para as recomendações que serão
feitas no item de riscos (item 4.3.8, Riscos, pag. 58) para que assim seus cronogramas
possuam a flexibilidade de absorver o impacto de riscos negativos que venham a ocorrer sem
que o andamento do projeto seja afetado de maneira intensa.
Por fim, sugere-se que a empresa elabore um histórico de desempenho de projetos
em relação ao tempo gasto em cada pacote de trabalho, armazenando-os em uma planilha de
dados. A consulta a este histórico será bastante útil para as estimativas de prazos feitas para
novos projetos, já que a quantidade de projetos que a empresa elabora a cada ano (e a
informação que há uma certa fidelização dos clientes) indica que muitos projetos poderão ter
atividades em comum.
Desta forma a empresa poderá, após a manutenção de seu histórico, verificar quais
são as atividades que mais consomem tempo em seus projetos, podendo tomar medidas que
diminuam estes prazos. Sendo feito um controle consistente a empresa evitará ter que
depender exclusivamente da experiência de seus funcionários. Poderá, também, promover
treinamentos nas atividades que se mostrarem mais deficientes, ou mesmo comparar os
funcionários entre si para que o profissional com o perfil mais adequado seja incumbido de
realizar as tarefas onde sua performance é melhor.
Não há necessidade de elaboração de documentos específicos para esta área de
conhecimento, além dos que já são utilizados pela empresa. Quanto aos softwares que a
empresa utiliza, o simples acréscimo da coluna "actual duration" no Microsoft Project será
suficiente para um controle inicial do tempo realmente despendido com as tarefas dos
projetos.
4.3.4 Custo
Na área de custos, observa-se bastante foco nos resultados, mas pouca ou nenhuma
padronização de processos para estimativa, monitoramento e controle de custos e de progresso
do projeto durante sua execução. A adoção de um processos baseado em boas práticas do
47
PMBoK para padronizar a orçamento, controle de custos e monitoramento de progresso, e o
conseqüente aumento de maturidade, poderia trazer melhoria na otimização do uso de
recursos humanos, maior previsibilidade financeira e, consequentemente, maior segurança nas
decisões sobre aplicação dos recursos financeiros, resultando em maior lucratividade.
A empresa em estudo, bem como outras do seu perfil, se caracteriza por produção e
fornecimento contínuo de diversos projetos de software de curta duração. Em função disso, os
custos abaixo, e similares, não serão considerados como custos de projeto, mas sim como
custo fixo da própria empresa, para manter sua atividade:
• Instalações físicas, luz, água, telefone e serviço de acesso à internet;
• Estações de trabalho e computadores dos desenvolvedores;
• Servidores internos de desenvolvimento.
Os custos dos projetos consistem basicamente na alocação de tempo dos Gerentes de
Projeto, Analistas de Sistema e Desenvolvedores na execução das atividades do projeto.
Portanto, o foco dentro dos projetos será dado para planejar, estimar e controlar estes custos,
referentes ao esforço de trabalho, baseada no tempo estimado para execução das atividades e
perfil de profissional alocado (GP, Analista, Programador), cada qual com seu respectivo
valor por hora trabalhada.
A primeira sugestão é que haja um processo de planejamento e estimativa de custos
do projeto. São utilizados os seguintes itens como entrada: lista de atividades, alocação de
atividades para perfil de profissional, valor hora para cada perfil profissional e cronograma
detalhado. Recomenda-se que a empresa adote os seguintes passos:
1. Criar plano de gerenciamento de custos conforme modelo padrão;
2. Com base na lista de atividades, alocação e valor/hora, calcular o custo de cada
atividade;
3. Com base no cronograma detalhado e nos custos por atividade, determinar a
distribuição dos custos no tempo dentro do projeto. Com isso obtém-se a linha base de
custos, possibilitando o seu controle no decorrer do projeto;
4. Documentar e Formalizar o Orçamento do Projeto internamente, e verificar desvios
com relação ao valor negociado com o cliente;
5. Caso haja desvios significativos, verificar necessidade de change request ou re-
negociação com o cliente.
48
Assim serão obtidos os seguintes documentos formais: orçamento e linha base de
custos.
Uma segunda sugestão é que a empresa adote um processo de controle de custos do
projeto. Os seguintes itens são necessários como entrada deste processo: orçamento (linha
base de custos), cronograma (linha base de tempo), WBS e Dicionário (linha base de escopo)
e informações coletadas sobre andamento das atividades. Os passos a serem seguidos pela
empresa, que deverão ser repetidos periodicamente, em intervalos definidos conforme o
tamanho e a criticidade do projeto, são os seguintes:
1. Gerente de Projeto coleta informações sobre o andamento das atividades já iniciadas e
não concluídas. Para isso, gera uma tabela conforme documentos sugeridos no
apêndice V (item 8.5.3, Error: Reference source not found, pag.154 e Error: Reference
source not found, pag. 155), a partir do sistema de controle de atividades, e preenche
os estimados para completar o projeto (estimate to complete the project - ETC´s) com
base em informação obtida com os recursos responsáveis por cada atividade;
2. O Gerente de Projeto insere as informações coletadas no sistema de controle
atividades (por exemplo, no Microsoft Project);
3. O Gerente de Projeto utiliza o sistema de controle de atividades para gerar os valores
dos indicadores descritos abaixo, do earned value analysis (EVA), e transcreve os
mesmos em relatório de progresso conforme os indicadores EVA mostrados na Error:
Reference source not found;
4. O Gerente de Projeto analisa os indicadores para identificar possível necessidade de
ações corretivas ou change requests;
5. O Gerente de Projeto dá início a ações corretivas ou change requests, quando
aplicável. Um Change Request, quando aprovado, deverá gerar alteração na linha base
de custos e, provavelmente, nas linhas base de tempo e escopo.
Tabela 7: Indicadores EVA.
49
50
Fonte: os próprios autores
Deste processo serão gerados os seguintes itens: relatório de progresso de custos,
change requests, ações corretivas e linha base de custos atualizada.
Por fim, sugere-se que a empresa adote as seguintes métricas para os processos de
custos:
51
• Percentual de esforço gasto nestas fases com relação ao esforço total do projeto: a
partir da estimativa inicial de esforço do projeto, utilizada para fechar o contrato com
o cliente (o que é feito antes da etapa de planejamento detalhado), pode-se determinar
qual o porcentual de tempo ou esforço/custo está sendo gasto com os referidos
processos, comparado com o esforço/tempo total do projeto. Isso possibilitará a
criação de uma base histórica que possibilitará estimativas mais realistas para estas
atividades em projetos futuros. Também possibilitará saber se um projeto está
gastando mais tempo que o normal com algum destes processos, possivelmente
trazendo a tona um problema de projeto que sem esta medição ficaria oculto por mais
tempo, podendo gerar mais prejuízos;
• Indicadores do EVA: a medição periódica destes indicadores também possibilitará a
geração de histórico, e a identificação precoce de problemas, comparando-se o mesmo
com o histórico existente. Além disso, poderá apontar prováveis problemas com o
processo de estimativa de tempo (e consequentemente de custos) para as atividades, ou
na própria execução das mesmas.
Recomenda-se que a empresa verifique estes indicadores quinzenalmente.
No apendice V são colocados modelos de documentos para as sugestões apresentadas
para o controle de escopo.
4.3.5 Qualidade
Analisando-se os resultados obtidos relacionados às questões de qualidade e de
estrutura da empresa, observou-se que as ações que resultam na qualidade dos serviços desta
têm como origem atitudes individuais de seus profissionais, não existindo um processo
institucionalizado.
Esta é uma excelente oportunidade para aprimorar ainda mais os serviços
desenvolvidos nesta empresa através da canalização dos esforços individuais em prol da
adoção de um sistema de gestão da qualidade que padronize processos objetivando a
constante busca pela qualidade e a melhoria contínua.
Segundo Marshall et al, 20072:"a padronização é de fundamental importância para as organizações. (...) Mas não basta padronizar processos, métodos, peças e componentes. É preciso melhorá-los continuamente. (...) A padronização também é importante para
2 MARSHALL Jr, I.; et al. Gestão da Qualidade. Rio de Janeiro: Editora FGV, 2007 – p. 83 - 84
52
permitir a análise crítica e a consequente melhoria dos procedimentos e métodos da empresa, pois propicia uma perspectiva concreta do que analisar e melhorar."
Como a empresa deseja implementar um programa de melhorias no processo de
gerência de seus projetos sem burocratizar em excesso e como seus profissionais possuem a
cultura de buscar a qualidade em suas atividades, sugere-se implementar um processo de
padronização partindo da forma como as atividades estão sendo desenvolvidas atualmente.
Neste sentido as idéias de Edwards Deming, um dos principais responsáveis pelo
movimento da qualidade no Japão, podem servir de base para a estruturação em questão.
Deming define a qualidade de acordo com as exigências e necessidades do consumidor e
como este está em permanente mudança, os processos em prol da qualidade devem ser
constantemente avaliados e adaptados sendo necessária a adoção de métodos gerenciais que
promovam estes processos.
O Ciclo PDCA ou Ciclo de Deming é um método gerencial para a promoção da
melhoria contínua introduzido no Japão após a guerra. Foi idealizado por Shewhart, na década
de 20, e divulgado por Deming, em 1950. Este ciclo adequa-se às necessidades da empresa
em estudo por ser um método amplamente aplicado para o controle eficaz e confiável das
atividades de uma organização que possibilita a padronização de processos e que, ao tornar as
informações mais entendíveis, diminui a probabilidade de erros nas análises.
Tal ciclo tem por princípio tornar mais claros e ágeis os processos envolvidos na
execução da gestão dividindo-a em quatro principais passos que formam a sigla PDCA
("Plan", planejar; “Do”, fazer ou agir; “Check”, checar ou verificar; “Action”, no sentido de
corrigir ou agir de forma corretiva).
O primeiro passo para a aplicação do PDCA é o estabelecimento de um plano de
ação (disponível no apêndice V, item 8.5.4, Error: Reference source not found, pag.156) que,
neste caso, deverá ser estabelecido com base nas diretrizes ou políticas da empresa e em
informações coletadas através de Brainstorming com os profissionais da empresa. Neste passo
destaca-se o estabelecimento dos objetivos e, com base nos objetivos selecionados, deve ser
feita a escolha do método a ser utilizado para que os objetivos sejam atingidos.
O segundo passo do PDCA é a execução do plano, a implementação do planejamento
realizado e a coleta de dados, ao longo da execução do plano, que serão verificados na
próxima fase. Tais dados devem ser armazenados na planilha de acompanhamento (disponível
no apêndice V, item 8.5.4, Error: Reference source not found, pag. 157).
53
O terceiro passo do PDCA é a análise dos resultados alcançados verificando se o
planejado foi alcançado através da comparação entre as metas estipulados e os resultados
obtidos. Esta análise poderá ser realizada através do Gráfico de Pareto, o que facilita a
priorização, e do Diagrama de Causa e Efeito.
A última fase do PDCA é a realização das ações corretivas, ou seja, a correção das
falhas encontradas no passo anterior e a adoção do que foi planejado e obteve sucesso como
padrão. Depois de realizada a investigação das causas das falhas ou desvios no processo,
deve-se repetir ou aplicar o ciclo PDCA para corrigir as falhas de forma a melhorar cada vez
mais o sistema e o método de trabalho.
A cada giro do Ciclo do PDCA, instala-se uma maior previsibilidade nos processos e
um consequente aumento da competitividade organizacional. Segundo Marshall et al, 20073:
“a previsibilidade acontece pela obediência aos padrões, pois, quando a melhoria é bem-
sucedida, adota-se o método planejado, padronizando-o; caso contrário, volta-se ao padrão
anterior e recomeça-se a girar o PDCA.”
No apendice V são colocados modelos de documentos para as sugestões apresentadas
para o controle de qualidade.
4.3.6 Recursos Humanos
Pelos dados fornecidos pela empresa e confirmados através dos resultados obtidos a
partir da aplicação do questionário, verifica-se que a empresa não possui um controle
arpimorado de Recursos Humanos.
A primeira sugestão, então, é que a empresa desenvolva um plano de cargos e
salários. Um cargo constitui uma unidade da organização e consiste em um conjunto de
deveres e responsabilidades que o tornam separado e distinto dos demais cargos. Na realidade,
os cargos constituem os meios através dos quais a empresa aloca e utiliza os seus recursos
humanos para alcançar objetivos organizacionais por meio de determinadas estratégias. Na
outra ponta, os cargos constituem os meios através dos quais as pessoas excutam as suas
tarefas dentro da organização para alcançar determinados objetivos individuais. Em resumo,
os cargos representam a pedra de toque entre a organização e as pessoas que nela trabalham.
A empresa Wasys poderia formalizar a existência de seus 4 principais cargos:
• Desenvolvedor: desenvolve o sistema em nivel de operação de software;
3 MARSHALL Jr, I.; et al. Gestão da Qualidade. Rio de Janeiro: Editora FGV, 2007 – p. 89 - 90
54
• Analista: analisa os requisitos do cliente e transforma em artefatos que auxiliam o
desenvolvedor e tambem documentam o projeto;
• Testador: testa o sistema e valida-o;
• Gerente: coordena a equipe, coordena cronograma, verifica os riscos e o contato com o
desenvovedor/arquiteto
O desenho contingencial de cargos é dinâmico e privilegia a mudança em função do
desenvolvimento pessoal do ocupante. Em outros termos, permite a adaptação do cargo ao
potencial de desenvolvimento pessoal do ocupante. Essa adaptação contínua é feita através do
enriquecimento do cargo. Enriquecimento de cargo significa a reorganização e ampliação do
cargo para proporcionar adequação ao ocupante no sentido de aumentar a satisfação intríseca
através do acréscimo de variedade, autonomia, significado das tarefas, identidade com as
tarefas e retroação. Segundo a teoria de dois fatores de Herzberg, o enriquecimento de cargo
constitui a maneira de obter satisfação intríseca através do cargo. É que o cargo é pequeno
demais para o espírito de muitas pessoas, e com o passar do tempo precisam ser
redimencionados. O enriquecimento do cargo -ou ampliação do cargo- torna-se a maneira
prática e viável para a adequação permanente do cargo ao crescimento profissinal do
ocupante. Consiste em aumentar deliberada e gradativamente os objetivos, responsabilidades
e desafios das tarefas do cargo para ajustá-los às características do ocupante. O
enriquecimento do cargo pode ser lateral ou horizontal (cargo lateral com a adição de novas
responsabilidades do mesmo nível) ou vertical (carga vertical com adição de novas
responsabilidades mais elevadas).
Sugere-se que a empresa formalize a matriz de responsabilidades de seus cargos. A
matriz de responsabilidades descreve as responsabilidades e funções dos envolvidos no
projeto, tendo por base os papéis identificados em seu organograma. A responsabilidade para
cada cargo de acordo com a atividade pode ser:
• RO – responsável pela operação;
• RC – responsável pelo controle;
• DC – deve ser consultado;
• DI – deve ser informado;
• RA – responsável pela aprovação
No apêndice V (item 8.5.5, Error: Reference source not found, pag.159) há um
exemplo de matriz de responsabilidade de um projeto da empresa estudada neste trabalho
55
Sugere-se, também, que a empresa formalize o processo de mobilização de equipes
para os projetos. Para tanto deve haver uma documentação e controle dos seguintes itens:
• cronograma de alocação: o cronograma de alocação tem como finalidade descrever a
necessidade de profissionais ao longo do tempo, especificando quando serão
solicitados, alocados e desalocados;
• regime de alocação: o regime de alocação descreve a forma como cada profissional
será alocado no projeto, descrevendo o total de horas trabalhadas e o regime de
alocação (parcial ou integral);
• pedido de alocação: o pedido de alocação deverá ser formalizado através do
encaminhamento superintendência competente, conforme política interna, quando
recursos inexistentes ou indisponíveis, e negociado com gerentes competentes, quando
recursos disponíveis em outras áreas.
Observou-se, também, que a empresa poderia ter benefícios em adotar um processo
de desenvolvimento da equipe. Este processo consiste em descrever o plano de
desenvolvimento que será utilizado para aprimorar as competências individuais e de grupo,
objetivando elevar o desempenho do projeto. É recomendável realizar este procedimento para
os funcionários que estão constantemente alocados em projetos de clientes com o qual se
possui um relacionamento duradouro e constante. Este desenvolvimento se faz, inclusive, com
a avaliação profissional dos funcionários, dando feedback para a equipe sobre o seu
desempenho no projeto. A avaliação de desempenho é uma apreciação sistemática do
desempenho de cada pessoa em função das atividades que ela desempenha, das metas e
resultados a serem alcançados e do seu potencial de desenvolvimento. A avaliação de
desempenho é um processo que serve para julgar ou estimar o valor, a excelência e as
qualidades de uma pessoa e, sobretudo a sua contribuição para o negócio da organização. Na
realidade, a avaliação do desempenho é um processo dinâmico que envolve o avaliado e seu
gerente e apresente uma técnica de direção imprescindível na atividade administrativa de hoje.
É um excelente meio através do qual se pode localizar problemas de supervisão de gerência,
de integração das pessoas a organização, de adequação de pessoas ao cargo, de localização de
possíveis dissonâncias e carências de treinamentos e, consequentemente, estabelecer os meios
e programas para eliminar ou neutralizar tais problemas. A avaliação de desempenho constitui
um poderoso meio de resolver problemas de desempenho e melhorar a qualidade do trabalho
e a qualidade de vida dentro das organizações.
56
Por fim, sugere-se que a empresa possua um processo definido para o recrutamento e
seleção de novos funcionários. O processo seletivo baseia-se em dados e informações sobre o
cargo a ser preenchido. As exigências dependem desses dados e informações para que a
seleção tenha maior objetividade e precisão para preencher o cargo. Se de um lado temos o
cargo a ser preenchido, temos, de outro, candidatos profundamente diferentes entre si,
disputando a mesma posição. Nestes termos, a seleção passa a ser configurada basicamente
como um processo de comparação e de decisão. A empresa deverá utilizar, para cada caso,
um tipo diverso de processo seletivo. Para conhecimento, elencamos a seguir os tipos mais
comuns:
• Modelo de colocação: há um só candidato e uma só vaga a ser preenchida por aquele
candidato. Este modelo não inclui a alternativa de rejeitar o candidato. O candidato
apresentado deve ser admitido sem sofrer qualquer rejeição;
• Modelo de seleção: há vários candidatos e apenas uma vaga a ser preenchida. Cada
candidato é comparado com os requisitos exigidos pelo cargo que se pretende
preencher, ocorrendo duas alternativas, apenas: aprovação ou rejeição. Se aprovado, o
candidato deverá se admitido. Se reprovado, o candidato é dispensado do processo
seletivo, pois existem vários outros candidatos para o cargo e apenas um deles poderá
ocupá-lo;
• Modelo de classificação: Existem vários candidatos para cada vaga e várias vagas
para cada candidato. Cada candidato é comparado com os requisitos exigidos pelo
cargo que se pretende preencher. Ocorrem duas alternativas para o candidato: ser
aprovado ou rejeitado para aquele cargo. Se aprovado, é admitido. Se rejeitado, passa
a ser comparado com os requisitos exigidos para outros cargos que se pretende
preencher, até se esgotarem os cargos vagos e as alternativas restantes. Daí a
denominação classificação. Para cada cargo a ser preenchido ocorrem vários
candidatos que disputam, sendo que apenas um deles poderá ocupá-lo, se vier a ser
aprovado.
Tendo sido avaliadas as melhores práticas do OPM3 relacionadas à área de
gerenciamento de RH, as considerações formuladas acima devem ser suficientes para que a
empresa possa formalizar o controle de seus recursos humanos e, ao mesmo tempo, não
introduzir formalismos e burocracias que venham a atrapalhar o bom clima organizacional
existente. A área de recursos humanos é bastante crítica em empresas de pequeno porte, onde
57
há necessidade de um relacionamento bastante pessoal entre os funcionários. Caso a empresa
venha a mudar o seu perfil, aumentando o seu tamanho e a complexidade de seu quadro
funcional, todo um novo estudo deverá ser feito, sendo que as considerações feitas servirão de
ponto de partida.
4.3.7 Comunicação
O PMBoK classifica a área de Comunicação em projetos entre os seguintes grupos
de processos:
1. Planejamento das comunicações: determinar as necessidades de informações e
comunicações das partes interessadas no projeto;
2. Distribuição das informações: colocação das informações necessárias à disposição das
partes interessadas no momento certo;
3. Relatório de desempenho: coleta e distribuição das informações sobre o desempenho.
Inclui relatório de andamento, medição e progresso de previsão;
4. Gerenciar as partes interessadas: gerenciamento das comunicações para satisfazer os
requisitos das partes interessadas no projeto e resolver problemas com elas.
Para a empresa, sugere-se que haja a adoção de um plano de comunicação. O plano
de gerenciamento das comunicações faz parte ou é um plano auxiliar do plano de
gerenciamento do projeto. De acordo com o PMBoK plano de gerenciamento das
comunicações fornece:
• Os requisitos de comunicação das partes interessadas;
• As informações que serão comunicadas, inclusive o formato, conteúdo e nível de
detalhes;
• A pessoa responsável pela comunicação das informações;
• A pessoa ou os grupos que receberão as informações;
• Os métodos ou tecnologias usados para transmitir as informações, como memorandos,
email e, ou, comunicados à imprensa;
• A freqüência da comunicação, como, por exemplo, semanal;
• Os prazos para identificar processos para aumentar o nível e a cadeia gerencial
(nomes) para levar para níveis mais altos problemas que não podem ser resolvidos em
um nível hierárquico mais baixo;
58
• O método para atualizar e refinar o plano de gerenciamento das comunicações
conforme o projeto se desenvolve e avança;
• Glossário da terminologia comum (caso necessário)
Na empresa estudada, é possível identificar os seguintes itens que deverão estar
presentes no plano de comunicação:
1. Principais Stakeholders que precisam fornecer informações: Desenvolvedor, Analista;
2. Principais Stakeholders que precisam receber informações: Cliente, Gerente do
Projeto, Desenvolvedor;
3. Principais informações que precisam ser distribuidas: Andamento dos projetos
(Etapas), orçamento dos projetos (EVA), não conformidades e ações corretivas;
4. Métodos, mídias ou tecnologias a serem utilizadas: email, edital, telefone, reuniões;
5. Frequência de comunicações:
• email: diário;• edital: semanal;• relefone: diário;• reuniões: quinzenais;
6. Métodos para escalação de problemas: relatório de EVA, relatório de não
conformidade, relatório de desempenho (informações e progresso das atividades);
7. Glossário (conjunto de termos a serem utilizados)
Além dos documentos trazidos no apêndice V, de outras áreas de conhecimento,
mostra-se também na pag. 160 um exemplo de "Relatório de Não-conformidades".
4.3.8 Riscos
Quanto ao controle de risco, verifica-se que a empresa não possui controle algum de
risco, o que indica que os problemas são resolvidos conforme surgem. Desta forma não é
gerado nenhum histórico de riscos dos projetos, inclusive para que pudessem ser realizadas
ações preventivas.
O PMBoK apresenta duas modalidades de gerenciamento de riscos: através da
análise qualitativa dos riscos (por exemplo, com conceitos como "alto" ou "baixo" e a análise
quantitativa, onde é verificado a probabilidade de ocorrência de cada risco e o seu impacto.
Apesar de ser mais simples de ser utilizado, principalmente em situações onde não
existe um histórico a fornecer estatísticas mais precisas, não é aconselhado que a empresa
adote a análise qualitativa.
59
Recomenda-se que a empresa inicie sua gerência de riscos com os seguintes passos:
1. Através de reunião com a sua equipe interna, seja feito um levantamento de riscos que
podem ocorrer durante a execução do projeto. Não apenas os riscos negativos (que
trazem atrasos ou perdas financeiras), mas também os riscos positivos, que são as
oportunidades de ganho para a empresa;
2. Elencados os riscos, seja preenchida a planilha que está presente no apêndice V (item
8.5.7, Levantamento de riscos, pag.161) fazendo-se o mapeamento entre os riscos e as
áreas de conhecimento a que se referem;
3. A seguir faz-se uma análise da probabilidade de ocorrência de cada um dos riscos. A
fonte mais confiável seria a opinião de especialistas e os históricos dos projetos;
4. O próximo passo é verificar qual o impacto de cada um dos riscos. Como a empresa
atua com pequenas equipes, fortemente integradas, é interessante analisar não só
impacos financeiros, mas também impactos de cronograma de cada um dos riscos;
5. Calcula-se, então, o impacto previsto de cada um dos riscos (probabilidade x impacto
esperado), para se saber quais serão os impactos esperados em cada um dos riscos.
A empresa também pode atuar na prevenção de riscos. Para isto deverá utilizar os
riscos previstos, selecionar quais serão os riscos onde deseja atuar (seja pelo seu impacto, seja
pela sua probabilidade de acontecimento, ou até mesmo pela experiência anterior em lidar
com aquele risco). A seguir deverá utilizar o documento Mitigação de Riscos (item 8.5.7, pag.
162) para estabelecer o plano de ação que será executado para mitigação dos riscos negativos
(ou potencialização dos riscos positivos).
4.3.9 Aquisições
O PMBoK classifica as aquisições do projeto como uma área de conhecimento
específica e cujos processos estão descritos no capítulo 12: “Gerenciamento de aquisições do
projeto”, onde estão divididos em:
• Planejar compras e aquisições: determinação do que comprar ou adquirir e de quando
e como fazer isso;
• Planejar contratações: documentação dos requisitos de produtos, serviços e resultados
e identificação de possíveis fornecedores;
• Solicitar respostas de fornecedores: obtenção de informações, cotações, preços, ofertas
ou propostas, conforme adequado;
60
• Selecionar fornecedores: análise de ofertas, escolha entre possíveis fornecedores e
negociação de um contrato por escrito com cada fornecedor;
• Administração de contrato: gerenciamento do contrato e da relação entre o comprador
e o fornecedor, análise e documentação do desempenho atual ou passado de um
fornecedor a fim de estabelecer ações corretivas necessárias e fornecer uma base para
futuras relações com o fornecedor, gerenciamento de mudanças relacionadas ao
contrato e, quando adequado, gerenciamento da relação contratual com o comprador
externo do projeto;
• Encerramento do contrato: terminar e liquidar cada contrato, inclusive a resolução de
quaisquer itens em aberto, e encerrar cada contrato aplicável ao projeto ou a uma fase
do projeto.
A aplicação do formulário de avaliação da empresa resultou em respostas, referente a
área de conhecimento Gerenciamento de Aquisições, que permitem afirmar que pela natureza
dos negócios da empresa, na qual pode ser classificada como “Fábrica de Software” que quase
sempre faz o papel de fornecedora e, somada às características dos projetos desenvolvidos,
tem-se a situação onde raramente demandam-se aquisições externas. Desta forma o conjunto
de Boas Práticas referentes a gerenciamento de aquisições não necessita ser implantado em
sua totalidade, pois criar-se-á uma burocracia desnecessária.
As aquisições para a empresa tendem a configurar duas situações principais que são a
aquisição de serviços ou produtos das quais a empresa não tem know-how ou não seja um dos
seus focos de atuação, mas cujo escopo do projeto vem a exigir; e a segunda situação é na
qual apesar da empresa possuir o know-how necessário para o desenvolvimento do projeto,
opta por contratar um fornecedor para desenvolver o projeto em sua totalidade ou de forma
parcial.
Dentro do contexto da empresa os processos onde será dado o foco são: Planejar
Compras e Aquisições e Planejar Contratações, ou seja, a seguinte boa prática será
implementada: “1150 Padronização do processo de Aquisição projeto”. As boas práticas
referentes ao encerramento do projeto, da qual o gerenciamento de aquisição possui
atividades, também serão implantadas e estão descritas no item 4.3.1 (pag. 35) referente ao
gerenciamento de integração do projeto.
61
O processo de planejamento de compras e aquisições é onde é feita a identificação
das necessidades do projeto que serão melhor atendidas através da contratação ou compra de
serviços ou produtos fora da organização. Para esta identificação pode-se utilizar a análise
make-or-buy, que consiste em uma série de ponderações a respeito das diversas necessidades
e pode orientar para executar dentro da organização ou adquirir externamente. O fluxograma
da figura7 deverá ser utilizado pela organização para auxiliar no processo decisório através da
análise make-or-buy.
Figura 7: Fluxograma do processo de decisão make-or-buy(Fonte: os próprios autores)
O processo de planejamento de compras e aquisições deverá utilizar as seguintes
entradas: declaração de escopo, WBS, dicionário da WBS. Os passos a serem seguidos são os
representados na figura 7 acima. Deste processo resultarão os seguintes documentos: plano de
gerenciamento de aquisição, decisões de fazer ou comprar.
Já o processo de planejamento das contratações consiste em elaborar toda a
documentação necessária para a aquisição externa de produtos ou serviços necessários para
atender os requisitos do projeto. É a sequência natural do processo de planejamento das
62
compras e aquisições. As saídas típicas deste processo são os documentos de aquisição,
critérios de avaliação e as declarações de trabalho. Os documentos de aquisição são utilizados
para enviar aos possíveis fornecedores as informações necessárias para que sejam elaboradas
as propostas. Os critérios de avaliação são os conjuntos de critérios para classificar e pontuar
propostas e fornecedores. E a declaração de trabalho é a especificação detalhada dos
requisitos do que está sendo adquirido.
Para a empresa em análise, levando-se em conta o pequeno porte, a reduzida
quantidade e necessidades de aquisições externas, assim como a relação de parceria que
desenvolve com seus fornecedores, o processo de planejamento de contratações deve ser
simples e efetivo. Para os documentos de aquisição devem ser fornecidas informações
suficientes para que o fornecedor possa avaliar custos e formalizar uma proposta. Para a
simplificação do processo optou-se pela junção do documento de aquisição com a declaração
de trabalho. As informações mínimas devem ser: nome do projeto, necessidade, objetivos,
escopo, restrições, premissas, entregáveis, critérios de aceite e matriz de responsabilidades. O
item 8.5.8 (Error: Reference source not found, pag 163) mostra o modelo de Declaração de
Trabalho que deve ser utilizado.
Ao final do processo de planejamento das contratações, o gerente de projetos ainda
deve preencher o plano de gerenciamento das contrações. O item 8.5.8 (Error: Reference
source not found, pag. 164) mostra o modelo de plano de gerenciamento de contrações que
deve ser utilizado.
Pelo fato da empresa não ter um departamento formal de compras e aquisições a
elaboração de critérios de avaliação de propostas e fornecedores é uma atividade
desnecessária, uma vez que a avaliação e escolha do fornecedor é em geral efetuada pelo
gerente de projetos em conjunto com o diretor técnico e o responsável por compras.
Os demais processos de aquisição sugeridos pelo PMBoK (solicitar respostas dos
fornecedores, selecionar fornecedores, administração de contratos) não serão estabelecidos ou
serão utilizados os processos já documentados e utilizados no Sistema de Controle da
Qualidade.
63
5 CONCLUSÕES
O objetivo deste trabalho foi identificar o grau de maturidade da empresa estudada
em gerência de projetos. Para tanto, após entrevistas efetuadas com um de seus sócios-deireto,
foi escolhido o OPM3, do PMI, como modelo de referência para o nível de maturidade, pois a
empresa conhece e utiliza o PMBOK em seus projetos.
Conforme o perfil da empresa, obtido através de levantamento efetuado por um de
seus sócios, foi determinado que o objeto de estudo seriam apenas as Best Practices do OPM3
que fossem relacionadas a projetos, não sendo trabalhadas as que se referem a programa ou
portfólio.
Verificou-se que é possível associar a maior parte das Best Practices com áreas de
conhecimento do PMBOK, restando poucas Best Practices que abrangem mais de uma área
de conhecimento ou que se referem à cultura organizacional da empresa. Facilita-se, assim, o
trabalho de implantação das práticas escolhidas, pois há uma integração mais forte com o
PMBOK.
Dentre estas Best Practices foram selecionadas algumas, reduzindo-se de um total de
208 Best Practices para 88. O critério de seleção foi o perfil de empresa, os profissionais que
a compõe, seu relacionamento com seus clientes e características de seus produtos. Evitou-se,
desta forma, que a empresa fosse avaliada profundamente em relação a áreas de conhecimento
do PMBOK que não são utilizadas em sua atividade. Neste ponto, destacamos a redução
significativa de Best Practices que se relacionam com as áreas de Aquisições, RH, Integração
e Comunicação.
O questionário elaborado conforme as Best Practices escolhidas tras 73 perguntas,
um número maior que o apresentado pelo OPM3 (59 perguntas relacionadas a projetos).
Buscou-se, desta forma, desdobrar alguns assuntos em várias perguntas, obtendo-se uma
avaliação mais precisa do nível de maturidade da empresa em gerenciamento de projetos.
Concluiu-se que a escolha do modelo OPM3 foi bastante coerente com a realidade da
empresa, pois após a aplicação do questionário elaborado verificou-se que as notas obtidas
nas áreas de conhecimento ou nos índices de maturidade da empresa em gerenciamento de
projetos era bastante coerente com o que havia sido levantado através de entrevista.
Por fim, a partir de todos estes dados levantados, foi feita uma análise e apresentadas
sugestões de como a empresa poderia adotar práticas recomendadas pelo OPM3 e pelo
PMBoK para aumentar o seu nível de maturidade. Houve cuidado de não interferir na cultura
64
já existente na empresa, para que não houvesse uma quebra de produtividade ou de confiança
em função de uma formalidade que poderia parecer injustificada.
Só será possível saber do êxito das sugestões feitas após uma nova avaliação da
empresa, em cerca de 6 meses, sendo imprescindível que a empresa implemente as sugestões
ou justifique a sua não utilização.
65
6 POSSÍVEIS DESDOBRAMENTOS
Este trabalho foi além do simples levantamento de dados da empresa apóes o estudos
de modelos de maturidade em gerência de projetos. As sugestões formuladas, a partir da
análise das respostas fornecidas pela empresa, só surtirão efeito após a sua implantação por
um tempo razoável, não sendo esperado grandes alterações em um prazo inferior a seis meses.
A equipe deste trabalho sugere que a empresa refaça sua análise, com auxílio do questionário
elaborado, a cadas semestre, podendo assim avaliar se houveram ganhos com a adoção das
sugestões.
66
7 REFERÊNCIAS BIBLIOGRÁFICAS
BARBOSA, C. et al. Gerenciamento de custos em projetos, Editora FGV, 2007
BARCAUI A, B. et al. Gerenciamento do tempo em projetos - 2ª edição, Editora FGV, 2008
______________ O Desafio do Sucesso em Projetos de Tecnologia da Informação, em Programa de Engenharia de Produção, Universidade Federal do Rio de Janeiro (UFRJ).
CHAVES, L. E. et al. Gerenciamento da comunicação em projetos, Editora FGV, 2007
FAGUNDES, Eduardo Mayer. Capability Maturity Model for Software. Disponível em http://www.efagundes.com/artigos/CMM.htm. Acesso em 28/11/2008.
GASNIER, Daniel G. Guia Prático Para Gerenciamento De Projetos. IMAM, 2003
MARSHALL Jr, I.; et al. Gestão da Qualidade. Rio de Janeiro: Editora FGV, 2007
OPM3 Knowledge Foundation. Organizational Project Management Maturity Model. Newton Square, PA. EUA, 2003.
PASSOS, Maria Luiza Gomes de Souza. Gerenciamento De Projetos Para Pequenas Empresas. Brasport, 2008
PAULK, M. C. et al. Capability Maturity Model for Software, Version 1.1, Technical Report SEI-CMU-93-TR-24, Software Engineering Institute, 1993.
PMI. Project Management Body of Knowledge (PMBoK). Project Management Institute. Newton Square, PA. EUA, 2004.
PRADO, D., ARCHIBALD, R. Pesquisa Sobre Maturidade em Gerenciamento de Projetos, Relatório Anaual – 2006. Disponível em www.maturityresearch.com. Acesso em 26/11/2008
___________. Gerenciamento de Portifólios, Programas e Projetos nas Organizações. São Paulo, INDG, 2004.
RAJ,P. P. et al. Gerenciamento de pessoas em projetos, Editora FGV, 2008
SALLES JR, C. A. C. et al. Gerenciamento de riscos em projetos, Editora FGV, 2007
SOTILLE, M. A. et al. Gerenciamento do escopo em projetos - 2ª edição, Editora FGV, 2008
VALLE, A. B. do et al. Fundamentos do gerenciamento de projetos, Editora FGV, 2007
VARGAS, R. V. Gerenciamento de Projetos Estabelecendo Diferenciais. Brasport, 2005
67
XAVIER, C. M. da S. . Gerenciamento de Projetos: como definir e controlar o escopo do projeto. Saraiva, 2008
__________________ et al. Gerenciamento de aquisições em projetos, Editora FGV, 2006
_______________________. Methodologia de Gerenciamento de Projetos: Methodware (3ª Edição). Brasport, 2005
68
8 APÊNDICES
8.1 APÊNDICE I – LISTA DE PERGUNTAS
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
8.2 APÊNDICE II – LISTA DE BOAS PRÁTICAS
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
8.3 APÊNDICE III – LISTA DE CORRESPONDÊNCIA ENTRE PERGUNTAS E BOAS
PRÁTICAS
131
132
133
8.4 APÊNDICE IV – LISTA DE PERGUNTAS E BOAS PRÁTICAS
Pergunta nº1PerguntaA sua organizaçao estabelece e usa padroes de processos de
documentacao para a iniciaçao do projeto?Número da Best PracticeBest
Practice1010Padronização do processo de inicio dos projetosPergunta nº2PerguntaHá um
processo de Planejamento do Escopo do Projeto?Número da Best PracticeBest
Practice1030Padronização do processo de planejamento do escopo de projetoPergunta
nº3PerguntaHá um processo de Padronizaçao do processo de definição do escopo de projeto?
Número da Best PracticeBest Practice1040Padronização do processo de definição do escopo
de projetoPergunta nº4PerguntaExiste um processo de Estimativa de Duraçao das Atividades
do Projeto?Número da Best PracticeBest Practice1070Padronização do processo de
Estimativa de Duração das Atividades do ProjetoPergunta nº5PerguntaExiste um processo de
padronização de estimativa de custo do projeto?Número da Best PracticeBest
Practice1100Padronização do processo de estimativa de custo do projetoPergunta
nº6PerguntaExiste padronização do processo de Aquisiçao projeto?Número da Best
PracticeBest Practice1150Padronização do processo de Aquisição projetoPergunta
nº7PerguntaExiste padronização do processo de Comunicaçao do projeto?Número da Best
PracticeBest Practice1160Padronização do processo de Comunicação do projetoPergunta
nº8PerguntaExiste padronização do processo de Execução do plano de projeto?Número da
Best PracticeBest Practice1230Padronização do processo de Execução do plano de
projetoPergunta nº9PerguntaExiste padronização do processo de Controle Integrado de
Mudanças do projeto?Número da Best PracticeBest Practice1310Padronização do processo
de Controle Integrado de Mudanças do projetoPergunta nº10PerguntaExiste padronização do
processo de Controle de qualidade do projeto?Número da Best PracticeBest
Practice1360Padronização do processo de Controle de qualidades do projetoPergunta
nº11PerguntaSão definidos Objetivos dos projetos?Número da Best PracticeBest
Practice1570Definir Objetivos do projetoPergunta nº12PerguntaExiste aprimoramento de
qualidade para atingir a satisfaçao do cliente?Número da Best PracticeBest
Practice1580Aprimorar qualidade para atingir a satisfação do clientePergunta
nº13PerguntaExiste estimativa de duraçao das tarefas do projeto?Número da Best
PracticeBest Practice1690Estimar duração das tarefas do projetoPergunta nº14PerguntaSua
organização estabelece e analisa métricas para serem utilizadas no acompanhamento da fase
134
de iniciação?Número da Best PracticeBest Practice2240Controles de processo de Iniciação
são estabelecidos e executados para controlar a estabilidade do processo.2250Controles de
processo de Desenvolvimento do Plano de Projeto são estabelecidos e executados para
controlar a estabilidade do processo.1710Estabelecer, compilar e analisar métricas do
processo de desenvolvimento do plano de projeto.1920Estabelecer, compilar e analisar
métricas do processo de planejamento de execução do plano.1700Estabelecer, compilar e
analisar métricas do processo de iniciação.Pergunta nº15PerguntaSua organização estabelece
e analisa métricas para serem utilizadas no acompanhamento da fase de planejamento de
escopo?Número da Best PracticeBest Practice2270Controles de processo de Definição de
Escopo são estabelecidos e executados para controlar a estabilidade do
processo.2010Estabelecer, compilar e analisar métricas do processo de verificação de
escopo.2260Controles de processo de Planejamento de Escopo são estabelecidos e executados
para controlar a estabilidade do processo.1720Estabelecer, compilar e analisar métricas do
planejamento de escopo.1730Estabelecer, compilar e analisar métricas do processo de
definição de escopo.Pergunta nº16PerguntaSua organização estabelece e analisa métricas para
serem utilizadas no acompanhamento da fase de planejamento de tempo?Número da Best
PracticeBest Practice2300Controles de processo de Estimativa de Duração de Atividades são
estabelecidos e executados para controlar a estabilidade do processo.2310Controles de
processo de Desenvolvimento de Cronograma são estabelecidos e executados para controlar a
estabilidade do processo.2280Controles de processo de Definição de Atividades são
estabelecidos e executados para controlar a estabilidade do processo.2290Controles de
processo de Sequenciamento de Atividades são estabelecidos e executados para controlar a
estabilidade do processo.1770Estabelecer, compilar e analisar métricas do processo de
desenvolvimento de cronograma.2030Estabelecer, compilar e analisar métricas do processo
de controle de cronograma.1750Estabelecer, compilar e analisar métricas do processo de
sequenciamento de atividades.1760Estabelecer, compilar e analisar métricas do processo de
estimativa de duração de atividades.1740Estabelecer, compilar e analisar métricas do
processo de definição de atividades.Pergunta nº17PerguntaSua organização estabelece e
analisa métricas para serem utilizadas no acompanhamento da fase de planejamento de custo?
Número da Best PracticeBest Practice2330Controles de processo de Estimativa de Custos são
estabelecidos e executados para controlar a estabilidade do processo.2340Controles de
processo de Orçamentação são estabelecidos e executados para controlar a estabilidade do
135
processo.2040Estabelecer, compilar e analisar métricas do processo de controle de
custos.2060Estabelecer, compilar e analisar métricas do processo de monitoramento e
controle de riscos.1790Estabelecer, compilar e analisar métricas do processo de estimativa de
custos.1800Estabelecer, compilar e analisar métricas do processo de orçamentação.Pergunta
nº18PerguntaSua organização estabelece e analisa métricas para serem utilizadas no
acompanhamento da fase de planejamento de qualidade?Número da Best PracticeBest
Practice2050Estabelecer, compilar e analisar métricas do processo de controle de
qualidade.2360Controles de processo de Planejamento da Gerência de Riscos são
estabelecidos e executados para controlar a estabilidade do processo.1820Estabelecer,
compilar e analisar métricas do processo da qualidade..1930Estabelecer, compilar e analisar
métricas do processo de garantia de qualidade.Pergunta nº19PerguntaSua organização
estabelece e analisa métricas para serem utilizadas no acompanhamento da fase de
planejamento das aquisições?Número da Best PracticeBest Practice1900Estabelecer,
compilar e analisar métricas do processo de planejamento de aquisições.1910Estabelecer,
compilar e analisar métricas do processo de planejamento de solicitação.Pergunta
nº20PerguntaSua organização estabelece e analisa métricas para serem utilizadas no
acompanhamento da fase de planejamento de Recursos Humanos?Número da Best
PracticeBest Practice1780Estabelecer, compilar e analisar métricas do processo de
planejamento de recursos.2320Controles de processo de Planejamento de Recursos são
estabelecidos e executados para controlar a estabilidade do processo.Pergunta
nº21PerguntaSua organização estabelece e analisa métricas para serem utilizadas no
acompanhamento da fase de planejamento de Riscos?Número da Best PracticeBest
Practice2400Controles de processo de Planejamento da Gerência de Riscos são estabelecidos
e executados para controlar a estabilidade do processo.1890Estabelecer, compilar e analisar
métricas do processo de planejamento de resposta aos riscos.2350Controles de processo de
Planejamento da Gerência de Riscos são estabelecidos e executados para controlar a
estabilidade do processo.1870Estabelecer, compilar e analisar métricas do processo de análise
qualitativa de riscos.1880Estabelecer, compilar e analisar métricas do processo de análise
quantitativa de riscos.1810Estabelecer, compilar e analisar métricas do processo de
planejamento da gerência de riscos.1860Estabelecer, compilar e analisar métricas do processo
de identificação de riscos.Pergunta nº22PerguntaSua organização estabelece e analisa
métricas para serem utilizadas no acompanhamento da fase de planejamento de Controle de
136
Mudanças?Número da Best PracticeBest Practice2020Estabelecer, compilar e analisar
métricas do processo de controle de mudanças de escopo.2000Estabelecer, compilar e analisar
métricas do processo de controle integrado de mudanças de projeto.Pergunta nº23PerguntaSua
organização aplica controles no acompanhamento da fase de iniciação?Número da Best
PracticeBest Practice2240Controles de processo de Iniciação são estabelecidos e executados
para controlar a estabilidade do processo.2250Controles de processo de Desenvolvimento do
Plano de Projeto são estabelecidos e executados para controlar a estabilidade do
processo.1710Estabelecer, compilar e analisar métricas do processo de desenvolvimento do
plano de projeto.1920Estabelecer, compilar e analisar métricas do processo de planejamento
de execução do plano.1700Estabelecer, compilar e analisar métricas do processo de
iniciação.Pergunta nº24PerguntaSua organização aplica controles no acompanhamento da fase
de planejamento de escopo?Número da Best PracticeBest Practice2270Controles de processo
de Definição de Escopo são estabelecidos e executados para controlar a estabilidade do
processo.2010Estabelecer, compilar e analisar métricas do processo de verificação de
escopo.2260Controles de processo de Planejamento de Escopo são estabelecidos e executados
para controlar a estabilidade do processo.1720Estabelecer, compilar e analisar métricas do
planejamento de escopo.1730Estabelecer, compilar e analisar métricas do processo de
definição de escopo.Pergunta nº25PerguntaSua organização aplica controles no
acompanhamento da fase de planejamento de tempo?Número da Best PracticeBest
Practice2300Controles de processo de Estimativa de Duração de Atividades são estabelecidos
e executados para controlar a estabilidade do processo.2310Controles de processo de
Desenvolvimento de Cronograma são estabelecidos e executados para controlar a estabilidade
do processo.2280Controles de processo de Definição de Atividades são estabelecidos e
executados para controlar a estabilidade do processo.2290Controles de processo de
Sequenciamento de Atividades são estabelecidos e executados para controlar a estabilidade do
processo.1770Estabelecer, compilar e analisar métricas do processo de desenvolvimento de
cronograma.2030Estabelecer, compilar e analisar métricas do processo de controle de
cronograma.1750Estabelecer, compilar e analisar métricas do processo de sequenciamento de
atividades.1760Estabelecer, compilar e analisar métricas do processo de estimativa de
duração de atividades.1740Estabelecer, compilar e analisar métricas do processo de definição
de atividades.Pergunta nº26PerguntaSua organização aplica controles no acompanhamento da
fase de planejamento de custo?Número da Best PracticeBest Practice2330Controles de
137
processo de Estimativa de Custos são estabelecidos e executados para controlar a estabilidade
do processo.2340Controles de processo de Orçamentação são estabelecidos e executados para
controlar a estabilidade do processo.2040Estabelecer, compilar e analisar métricas do
processo de controle de custos.2060Estabelecer, compilar e analisar métricas do processo de
monitoramento e controle de riscos.1790Estabelecer, compilar e analisar métricas do processo
de estimativa de custos.1800Estabelecer, compilar e analisar métricas do processo de
orçamentação.Pergunta nº27PerguntaSua organização aplica controles no acompanhamento
da fase de planejamento de qualidade?Número da Best PracticeBest Practice2050Estabelecer,
compilar e analisar métricas do processo de controle de qualidade.2360Controles de processo
de Planejamento da Gerência de Riscos são estabelecidos e executados para controlar a
estabilidade do processo.1820Estabelecer, compilar e analisar métricas do processo da
qualidade..1930Estabelecer, compilar e analisar métricas do processo de garantia de
qualidade.Pergunta nº28PerguntaSua organização aplica controles no acompanhamento da
fase de planejamento das aquisições?Número da Best PracticeBest Practice1900Estabelecer,
compilar e analisar métricas do processo de planejamento de aquisições.1910Estabelecer,
compilar e analisar métricas do processo de planejamento de solicitação.Pergunta
nº29PerguntaSua organização aplica controles no acompanhamento da fase de planejamento
de Recursos Humanos?Número da Best PracticeBest Practice1780Estabelecer, compilar e
analisar métricas do processo de planejamento de recursos.2320Controles de processo de
Planejamento de Recursos são estabelecidos e executados para controlar a estabilidade do
processo.Pergunta nº30PerguntaSua organização aplica controles no acompanhamento da fase
de planejamento de Riscos?Número da Best PracticeBest Practice2400Controles de processo
de Planejamento da Gerência de Riscos são estabelecidos e executados para controlar a
estabilidade do processo.1890Estabelecer, compilar e analisar métricas do processo de
planejamento de resposta aos riscos.2350Controles de processo de Planejamento da Gerência
de Riscos são estabelecidos e executados para controlar a estabilidade do
processo.1870Estabelecer, compilar e analisar métricas do processo de análise qualitativa de
riscos.1880Estabelecer, compilar e analisar métricas do processo de análise quantitativa de
riscos.1810Estabelecer, compilar e analisar métricas do processo de planejamento da gerência
de riscos.1860Estabelecer, compilar e analisar métricas do processo de identificação de
riscos.Pergunta nº31PerguntaSua organização aplica controles no acompanhamento da fase de
planejamento de Controle de Mudanças?Número da Best PracticeBest
138
Practice2020Estabelecer, compilar e analisar métricas do processo de controle de mudanças
de escopo.2000Estabelecer, compilar e analisar métricas do processo de controle integrado de
mudanças de projeto.Pergunta nº32PerguntaA organização segue metodologia e
procedimentos documentados para Gerência de Projetos?Número da Best PracticeBest
Practice2090A organização adere a um conjunto padrão de metodologias, processos e
procedimentos de Gerenciamento de ProjetosPergunta nº33PerguntaA organização apura e
documenta o retorno financeiro de projetos?Número da Best PracticeBest Practice2110A
organização demonstra o retorno de projetos executados.Pergunta nº34PerguntaA organização
apura e documenta o atingimento dos objetivos dos projetos?Número da Best PracticeBest
Practice2110A organização demonstra o retorno de projetos executados.Pergunta
nº35PerguntaA organização avalia performance individual e de equipe através de um processo
formal?Número da Best PracticeBest Practice2120A organização usa e mantém um sistema
formal de performance para avaliação individual e da equipePergunta nº36PerguntaA
organização premia performance individual e de equipe?Número da Best PracticeBest
Practice2180A organização avalia performance individual e de equipe e dá prêmios de acordo
com a estrutura dos projetos, atingimento de metas e cumprimento de prazos.Pergunta
nº37PerguntaOs objetivos do projeto são usados no acompanhamento do mesmo? O
atingimento dos mesmos é usado como critério de sucesso?Número da Best PracticeBest
Practice2140A organização define e revisa objetivos de projeto para assegurar que eles são
consistentes e atingíveis.2150A organização define critérios de sucesso no começo do projeto
e os mesmos são gerenciados e permanecem visíveis no decorrer do projeto.Pergunta
nº38PerguntaExiste um processo formal para definir se projetos serão ou não executados, se
submeterá proposta?Número da Best PracticeBest Practice2170O processo de priorização de
projetos é utilizado para ligar os projetos aos objetivos da organização.Pergunta
nº39PerguntaA organização aplica um processo formal de acompanhamento dos riscos
durante a execução do projeto?Número da Best PracticeBest Practice2200A organização
utiliza técnicas de gerência de risco para monitorar e acompanhar o impacto dos riscos
durante a execução do projeto.Pergunta nº40PerguntaHá um procedimento de controle de
riscos durante a execução do projeto?Número da Best PracticeBest Practice2400Controles de
processo de Planejamento da Gerência de Riscos são estabelecidos e executados para
controlar a estabilidade do processo.2430Processo de controle de planejamento de respostas a
riscos de projeto são estabelecidos e executados para controlar a estabilidade do
139
processoPergunta nº41PerguntaO procedimento de controle de riscos durante a execução do
projeto é aplicado?Número da Best PracticeBest Practice2400Controles de processo de
Planejamento da Gerência de Riscos são estabelecidos e executados para controlar a
estabilidade do processo.2430Processo de controle de planejamento de respostas a riscos de
projeto são estabelecidos e executados para controlar a estabilidade do processoPergunta
nº42PerguntaHá um procedimento para controle e acompanhamento da execução do projeto?
Número da Best PracticeBest Practice2460Processos de controle de execução do
planejamento do projeto são estabelecidos e executados para controlar a estabilidade do
processoPergunta nº43PerguntaO procedimento de controle e acompanhamento da execução
do projeto é aplicado?Número da Best PracticeBest Practice2460Processos de controle de
execução do planejamento do projeto são estabelecidos e executados para controlar a
estabilidade do processoPergunta nº44PerguntaHá um procedimento para controle de
mudanças de calendário do projeto?Número da Best PracticeBest Practice2570Processos de
controle de mudanças de calendário do projeto são estabelecidos e executados para controlar a
estabilidade do processoPergunta nº45PerguntaO procedimento de controle de mudanças de
calendário do projeto é aplicado?Número da Best PracticeBest Practice2570Processos de
controle de mudanças de calendário do projeto são estabelecidos e executados para controlar a
estabilidade do processoPergunta nº46PerguntaÉ feita uma estimativa de problemas que
poderão surgir sobre a estimativa das atividades que compõe o projeto?Número da Best
PracticeBest Practice2670Problemas na área do processo de definição de atividades são
estimadas, recomendações de melhoria do processo são coletadas, e melhorias do processo
são implementadas.2690Problemas na área do processo de estimativa de duração das
atividades são estimadas, recomendações de melhoria do processo são coletadas, e melhorias
do processo são implementadas.Pergunta nº47PerguntaÉ feita a coleta de informações sobre a
correção das atividades que foram estimadas para o projeto?Número da Best PracticeBest
Practice2670Problemas na área do processo de definição de atividades são estimadas,
recomendações de melhoria do processo são coletadas, e melhorias do processo são
implementadas.2690Problemas na área do processo de estimativa de duração das atividades
são estimadas, recomendações de melhoria do processo são coletadas, e melhorias do
processo são implementadas.Pergunta nº48PerguntaSão implementadas melhorias na
estimativa de atividades dos projetos baseando-se em informações coletadas em projetos
anteriores?Número da Best PracticeBest Practice2670Problemas na área do processo de
140
definição de atividades são estimadas, recomendações de melhoria do processo são coletadas,
e melhorias do processo são implementadas.2690Problemas na área do processo de estimativa
de duração das atividades são estimadas, recomendações de melhoria do processo são
coletadas, e melhorias do processo são implementadas.Pergunta nº49PerguntaHá um
procedimento de controle de mudanças de escopo durante a execução do projeto?Número da
Best PracticeBest Practice2560Processos de controle de mudanças de escopo do projeto são
estabelecidos e executados para controlar a estabilidade do processoPergunta nº50PerguntaO
procedimento de controle de mudanças de escopo durante a execução do projeto é aplicado?
Número da Best PracticeBest Practice2560Processos de controle de mudanças de escopo do
projeto são estabelecidos e executados para controlar a estabilidade do processoPergunta
nº51PerguntaÉ feita uma estimativa de problemas que poderão surgir sobre o escopo do
projeto?Número da Best PracticeBest Practice2650Problemas na área do processo de
planejamento de escopo do projeto são estimadas, recomendações de melhoria do processo
são coletadas, e melhorias do processo são implementadas.Pergunta nº52PerguntaÉ feita a
coleta de informações sobre problemas surgidos de escopo mal definido ou de mudanças de
escopo?Número da Best PracticeBest Practice2650Problemas na área do processo de
planejamento de escopo do projeto são estimadas, recomendações de melhoria do processo
são coletadas, e melhorias do processo são implementadas.Pergunta nº53PerguntaSão
implementadas melhorias no planejamento de escopo e no controle de mudança de escopo dos
projetos baseando-se em informações coletadas em projetos anteriores?Número da Best
PracticeBest Practice2650Problemas na área do processo de planejamento de escopo do
projeto são estimadas, recomendações de melhoria do processo são coletadas, e melhorias do
processo são implementadas.Pergunta nº54PerguntaHá um procedimento para elaboração de
relatórios de desempenho?Número da Best PracticeBest Practice2530Processos de controle
de relatórios de desempenho do projeto são estabelecidos e executados para controlar a
estabilidade do processoPergunta nº55PerguntaO relatório de desempenho é feito conforme
procedimento definido durante a execução do projeto?Número da Best PracticeBest
Practice2530Processos de controle de relatórios de desempenho do projeto são estabelecidos
e executados para controlar a estabilidade do processoPergunta nº56PerguntaHá um
procedimento para controle de mudanças de custos do projeto?Número da Best PracticeBest
Practice2580Processos de controle de mudanças de custo do projeto são estabelecidos e
executados para controlar a estabilidade do processoPergunta nº57PerguntaO procedimento
141
de controle de mudanças de custos do projeto é aplicado?Número da Best PracticeBest
Practice2580Processos de controle de mudanças de custo do projeto são estabelecidos e
executados para controlar a estabilidade do processoPergunta nº58PerguntaÉ feita uma
estimativa de problemas que poderão surgir sobre a estimativa de custos do projeto?Número
da Best PracticeBest Practice2720Problemas na área do processo de estimativa de custos são
estimadas, recomendações de melhoria do processo são coletadas, e melhorias do processo
são implementadas.Pergunta nº59PerguntaÉ feita a coleta de informações sobre problemas
surgidos de custos mal definidos?Número da Best PracticeBest Practice2720Problemas na
área do processo de estimativa de custos são estimadas, recomendações de melhoria do
processo são coletadas, e melhorias do processo são implementadas.Pergunta
nº60PerguntaSão implementadas melhorias na estimativa de custos dos projetos baseando-se
em informações coletadas em projetos anteriores?Número da Best PracticeBest
Practice2720Problemas na área do processo de estimativa de custos são estimadas,
recomendações de melhoria do processo são coletadas, e melhorias do processo são
implementadas.Pergunta nº61PerguntaÉ feita a coleta de informações sobre problemas
surgidos na elaboração de relatórios de desempenho?Número da Best PracticeBest
Practice2920Problemas na área do processo de relatório de desempenho são estimadas,
recomendações de melhoria do processo são coletadas, e melhorias do processo são
implementadas.Pergunta nº62PerguntaSão implementadas melhorias na elaboração de
relatório de desempenho baseando-se em informações coletadas em projetos anteriores?
Número da Best PracticeBest Practice2920Problemas na área do processo de relatório de
desempenho são estimadas, recomendações de melhoria do processo são coletadas, e
melhorias do processo são implementadas.Pergunta nº63PerguntaÉ feita a coleta de
informações sobre a ocorrência de riscos e as respostas dadas durante a execução do projeto?
Número da Best PracticeBest Practice2400Controles de processo de Planejamento da
Gerência de Riscos são estabelecidos e executados para controlar a estabilidade do
processo.2430Processo de controle de planejamento de respostas a riscos de projeto são
estabelecidos e executados para controlar a estabilidade do processoPergunta
nº64PerguntaSão implementadas melhorias no levantamento de riscos e no planejamento de
respostas a riscos baseando-se em informações coletadas em projetos anteriores?Número da
Best PracticeBest Practice2790Problemas na área do processo de identificação de riscos são
estimadas, recomendações de melhoria do processo são coletadas, e melhorias do processo
142
são implementadas.Pergunta nº65PerguntaHá um procedimento de encerramento de projetos?
Número da Best PracticeBest Practice2610Processos de controle de encerramento de contrato
do projeto são estabelecidos e executados para controlar a estabilidade do processoPergunta
nº66PerguntaO procedimento de encerramento de projetos é aplicado?Número da Best
PracticeBest Practice2610Processos de controle de encerramento de contrato do projeto são
estabelecidos e executados para controlar a estabilidade do processoPergunta nº67PerguntaÉ
feita a coleta de informações sobre problemas surgidos no processo de encerramento do
projeto?Número da Best PracticeBest Practice3000Problemas na área do processo de
encerramento de projeto são estimadas, recomendações de melhoria do processo são
coletadas, e melhorias do processo são implementadas.Pergunta nº68PerguntaSão
implementadas melhorias no processo de encerramento do projeto baseando-se em
informações coletadas em projetos anteriores?Número da Best PracticeBest
Practice3000Problemas na área do processo de encerramento de projeto são estimadas,
recomendações de melhoria do processo são coletadas, e melhorias do processo são
implementadas.Pergunta nº69PerguntaHá a coleta de informações de “lições aprendidas” no
projeto?Número da Best PracticeBest Practice3040A equipe de projeto captura, acessa,
recupera e aplica as lições aprendidas3030A empresa coleta e compartilha lições aprendidas
dos projetos, programas e portfolioPergunta nº70PerguntaAs informações de “lições
aprendidas” são compartilhadas pelas equipes de projetos?Número da Best PracticeBest
Practice3030A empresa coleta e compartilha lições aprendidas dos projetos, programas e
portfolioPergunta nº71PerguntaAs informações de “lições aprendidas” são utilizadas em
novos projetos?Número da Best PracticeBest Practice3040A equipe de projeto captura,
acessa, recupera e aplica as lições aprendidasPergunta nº72PerguntaÉ realizado benchmarking
para comparar o desempenho de projetos?Número da Best PracticeBest Practice3050A
empresa utiliza a técnica de benchmarking para melhorar continuamente o desempenho de
projetosPergunta nº73PerguntaHá apoio da empresa para as equipes de projeto através de
suporte técnico ou de um bom ambiente de trabalho?Número da Best PracticeBest
Practice3090A empresa cria um ambiente de trabalho que estimula o trabalho em equipe e
constrói confiança3100A empresa fornece apoio técnico-administrativo para equipes de
projeto.3070A empresa encoraja as equipes de projeto a assumir riscos calculados para
melhorar o desempenho dos projetos3080A empresa cria um ambiente de trabalho que apóia a
realização pessoal e profissional
143
144
8.5 APÊNDICE V: MODELOS DE DOCUMENTOS
8.5.1 Integração
Termo de abertura do Projeto
<Nome-Empresa>
Projeto: <Nome-Projeto>Termo de Abertura do ProjetoElaborado Por: <Nome e Função>Aprovador 1
(Empresa): <Assinatura>Data:
Objetivos
<Especificar os objetivos do projeto>
Gerente responsável
<Nome do gerente>
Responsáveis no cliente
<Nome do gerente>
Matriz de responsabilidades
<Inserir os nomes do Gerente do Projeto, do Programador Líder e dos Programadores>
Escopo
<Colocar o escopo macro colocado na proposta>
Restrições
<Inserir todas as restrições colocado na proposta>
Premissas
<Inserir todas as premissas do entregável>
Principais Milestones
<Inserir as principais milestones do projeto, sendo obrigatório as seguintes: data de início do
projeto, data de início da análise, data fim da análise, data de início do desenvolvimento, data
fim do desenvolvimento, data de início dos testes, data fim dos testes, data de início da
homologação, data fim da homologação, data fim do projeto>
145
Plano de Gerenciamento do Projeto
<Nome-Empresa>
Projeto: <Nome-Projeto>Plano Gerenciamento do projetoElaborado Por: <Nome e Função>Aprovador 1
(Empresa): <Assinatura>Data:Objetivos
<Especificar os objetivos do projeto>
Responsabilidades
<Inserir a matriz de responsabilidades e listar, para cada membro, os entregáveis dos quais
são responsáveis>
Escopo
<Linkar para o termo de abertura do projeto, WBS e dicionário da WBS>
Milestones
<Linkar para o termo de abertura do projeto>
Cronograma
<Linkar para o documento de cronograma do projeto>
Metodologia de desenvolvimento
<Descrever a metodologia de desenvolvimento>
Gerenciamento de mudanças
<Descrever a metodologia do plano de integrado de mudança>
Plano de Qualidade
<Linkar para o documento de plano da qualidade>
Plano de Gerenciamento de Pessoal
<Linkar para o documento de plano de RH>
Plano de Comunicação
<Linkar para o documento de plano da gerenciamento de riscos>
Plano de Gerenciamento de Riscos
<Linkar para o documento de plano da gerenciamento de riscos>
146
Solicitação de mudanças
<Nome-Empresa>
Projeto: <Nome-Projeto>Solicitação de mudançasElaborado Por: <Nome e Função>Aprovador 1
(Empresa): <Assinatura>Data:
Número Data Solicitante
Mudança solicitada
<Especificar a mudança solicitas>
Justificativa
<Especificar a justificativa e motivos da mudança>
Avaliação dos impactos:
Ação recomendada
<Especificar a ação a ser tomada>
147
148
Lições aprendidas
<Nome-Empresa>
Projeto: <Nome-Projeto>Lições aprendidasElaborado Por: <Nome e Função>Aprovador 1 (Empresa):
<Assinatura>Data:
149
8.5.2 Escopo
WBS
<Nome-Empresa>
Projeto: <Nome-Projeto>Estrutura Analítica do ProjetoElaborado Por: <Nome e Função>Aprovador 1
(Empresa): <Assinatura>Data:Aprovador 2 (Cliente): <Assinatura>Data:
150
Dicionário da WBS<Nome-Empresa>
Projeto: <Nome-Projeto>Dicionário da Estrutura Analítica do ProjetoElaborado Por: <Nome e
Função>Aprovador 1 (Empresa): <Assinatura>Data:Aprovador 2 (Cliente): <Assinatura>Data:
151
Formulário de Aceite de Item de Escopo
<Nome-Empresa>
Projeto: <Nome-Projeto>Aceite de Produtos ou ServiçosElaborado Por: <Nome e Função>Aprovador
1 (Empresa): <Assinatura>Data:Aprovador 2 (Cliente): <Assinatura>Data:
1. Descrição dos Produtos ou Serviços Entregues
<Listar e descrever os produtos e serviços entregues, referenciando o número dos mesmos no
dicionário da EAP>
2. Observações:
<Descrever as observações pertinentes ao aceite>
152
8.5.3 Custos
Plano de Gerenciamento de Custos
<Nome-Empresa>
• Projeto: <Nome-Projeto>Plano de Gerenciamento de CustosElaborado Por: <Nome e Função>Aprovador 1 (Empresa): <Assinatura>Data:Relação de processos a utilizar
Estimativa de Custos<Particularidades do processo para este projeto>Orçamentação<Particularidades do processo para este projeto>Controle de Custos<Particularidades do processo para este projeto>
• Relação de Relatórios a utilizar<Lista de tipos de relatórios a utilizar, elencando identificação de documentos de template>
• Forma de estimativa<Relacionar particularidades de estimativa de custos do projeto que fujam do processo padrão adotado>
• Indicadores para Controle<Lista de Indicadores, explicando forma de cálculo e coleta de dados, bem como os limites adotados para o projeto em questão >
• Processo de gerenciamento de variações<Quais os procedimentos a adotar no caso de variações/estouro de limites estabelecidos para indicadores>
• Gerenciamento de MudançasProcesso de solicitação de mudanças(Vide área de Gerenciamento de Integração)Template de solicitação de mudanças<Identificação do documento>(Vide área de Gerenciamento de Integração)Descrição/Observação sobre processo de gerenciamento de mudanças<Particularidades deste projeto sobre o processo de gerenciamento de mudanças>(Vide área de Gerenciamento de Integração)
153
Orçamento<Nome-Empresa>Projeto: <Nome-Projeto>OrçamentoDados Coletados Por: <Nome e
Função>Elaborado por: <Nome e Função>Data de Aprovação: __ / __ / ____Orçamento por Recurso
Recurso / Perfil Custo unitário /
Valor Hora (R$)
Quantidade (Horas) Sub-total (R$)
Custo do projeto
Adicional de Risco para Valor Esperado
Reserva Gerencial / Taxa de Administração 5%
Custo Final
Orça
mento por Use Case<local>, em ___ de _________ de _____
_______________________________________________________
ASSINATURAS <principais envolvidos>
154
Formulário de informações de progresso das atividades
<Nome-Empresa>Projeto: <Nome-Projeto>Aceite de Produtos ou ServiçosDados
Coletados Por: <Nome e Função><Assinatura>
155
Relatório de Progresso
<Nome-Empresa>Projeto: <Nome-Projeto>Relatório de DesempenhoElaborado Por:
<Nome e Função>Aprovado por: <Nome e Função> <Assinatura>1. Situação das
EntregasPrazo (Cronograma)
Custo
(Orçamento)
Anális
e do Valor Agregado (EVA)
Estim
ativas de conclusãoENT (ONT / IDC):
156
8.5.4 Qualidade
Plano de Ação
<Nome-Empresa>
Projeto: <Nome-Projeto>Gestão da Qualidade - Plano de AçãoElaborado Por: <Nome e
Função>Aprovador 1 (Empresa): <Assinatura>Data:Aprovador 2 (Cliente): <Assinatura>Data:
157
Planilha de Acompanhamento
<Nome-Empresa>
Projeto: <Nome-Projeto>
Planilha de Acompanhamento
Revisado Por: <Nome e Função>
Aprovador 1 (Empresa): <Assinatura>
Data:
Aprovador 2 (Cliente): <Assinatura>
Data:
Ação Implementada
Ocorrência
Resposta
Data da Ocorrência
Responsável pelo Registro
158
159
8.5.5 Recursos Humanos
Matriz de responsabilidades
160
8.5.6 Comunicação
Relatório de Não-conformidades
161
8.5.7 Riscos
Levantamento de riscos
<Nome-Empresa>
Projeto: <Nome-Projeto>
Planilha de Acompanhamento
Data: Responsável
Id Risco Área Probabilidade Impacto
Financeiro
Impacto em
Dias
162
Mitigação de Riscos
<Nome-Empresa>
Projeto: <Nome-Projeto>
Planilha de Acompanhamento
Data:
Id Risco Ação Responsável Prazo
163
8.5.8 Aquisições
Declaração de Trabalho
<Nome-Empresa>
Projeto: <Nome-Projeto>Declaração de trabalhoElaborado Por: <Nome e Função>Aprovador 1
(Empresa): <Assinatura>Data:
Necessidade
<Especificar de forma sucinta a necessidade de aquisição>
Objetivos
<Especificar os objetivos da requisição>
Escopo
<Detalhar o escopo da necessidade, expandido e especificando o detalhamento já inserido na
WBS>
Restrições
<Inserir todas as restrições do entregável, sejam técnicas, sejam de prazo>
Premissas
<Inserir todas as premissas do entregável>
Entregáveis
<Inserir todos os produtos e objetivos que deverão ser entregues>
Critérios de aceite
<Inserir todas os critérios de avaliação do entregável e para a sua aceitação>
Matriz de responsabilidades
<Inserir os nomes do Gerente do Projeto, do Diretor técnico e do responsável por compras>
164
Plano de Gerenciamento de Contrações
<Nome-Empresa>
Projeto: <Nome-Projeto>Plano de Gerenciamento de ContraçõesElaborado Por: <Nome e
Função>Aprovador 1 (Empresa): <Assinatura>Data:
Itens e recursos a serem contratados ou adquiridos
<Listar todos os itens a serem contratados ou adquiridos de acordo com a análise make-or-
buy>
Documentação necessária para cada contratação
<Listar para cada item a ser contratado ou adquirido os documentos necessários para a sua
contratação, o documento mínimo e a declaração de trabalho do item>
165
8.6 APÊNDICE VI: QUESTIONÁRIO RESPONDIDO PELA EMPRESA
N. Pergunta
Descrição Nota (0 a 5)
1 A sua organizaçao estabelece e usa padroes de processos de documentacao para a iniciaçao do projeto?
1
2 Há um processo de Planejamento do Escopo do Projeto? 5
3 Há um processo de Padronizaçao do processo de definição do escopo de projeto? 0
4 Existe um processo de Estimativa de Duraçao das Atividades do Projeto? 3
5 Existe um processo de padronização de estimativa de custo do projeto? 0
6 Existe padronização do processo de Aquisiçao projeto? 0
7 Existe padronização do processo de Comunicaçao do projeto? 0
8 Existe padronização do processo de Execução do plano de projeto? 0
9 Existe padronização do processo de Controle Integrado de Mudanças do projeto? 3
10 Existe padronização do processo de Controle de qualidade do projeto? 3
11 São definidos Objetivos dos projetos? 1
12 Existe aprimoramento de qualidade para atingir a satisfaçao do cliente? 0
13 Existe estimativa de duraçao das tarefas do projeto? 5
14 Sua organização estabelece e analisa métricas para serem utilizadas no acompanhamento da fase de iniciação?
0
15 Sua organização estabelece e analisa métricas para serem utilizadas no acompanhamento da fase de planejamento de escopo?
0
16 Sua organização estabelece e analisa métricas para serem utilizadas no acompanhamento da fase de planejamento de tempo?
0
17 Sua organização estabelece e analisa métricas para serem utilizadas no acompanhamento da fase de planejamento de custo?
0
18 Sua organização estabelece e analisa métricas para serem utilizadas no acompanhamento da fase de planejamento de qualidade?
0
19 Sua organização estabelece e analisa métricas para serem utilizadas no acompanhamento da fase de planejamento das aquisições?
0
20 Sua organização estabelece e analisa métricas para serem utilizadas no acompanhamento da fase de planejamento de Recursos Humanos?
0
21 Sua organização estabelece e analisa métricas para serem utilizadas no acompanhamento da fase de planejamento de Riscos?
0
22 Sua organização estabelece e analisa métricas para serem utilizadas no acompanhamento da fase de planejamento de Controle de Mudanças?
0
23 Sua organização aplica controles no acompanhamento da fase de iniciação? 0
24 Sua organização aplica controles no acompanhamento da fase de planejamento de escopo?
0
25 Sua organização aplica controles no acompanhamento da fase de planejamento de tempo?
0
166
N. Pergunta
Descrição Nota (0 a 5)
26 Sua organização aplica controles no acompanhamento da fase de planejamento de custo?
0
27 Sua organização aplica controles no acompanhamento da fase de planejamento de qualidade?
0
28 Sua organização aplica controles no acompanhamento da fase de planejamento das aquisições?
0
29 Sua organização aplica controles no acompanhamento da fase de planejamento de Recursos Humanos?
0
30 Sua organização aplica controles no acompanhamento da fase de planejamento de Riscos?
0
31 Sua organização aplica controles no acompanhamento da fase de planejamento de Controle de Mudanças?
0
32 A organização segue metodologia e procedimentos documentados para Gerência de Projetos?
2
33 A organização apura e documenta o retorno financeiro de projetos? 5
34 A organização apura e documenta o atingimento dos objetivos dos projetos? 2
35 A organização avalia performance individual e de equipe através de um processo formal?
0
36 A organização premia performance individual e de equipe? 0
37 Os objetivos do projeto são usados no acompanhamento do mesmo? O atingimento dos mesmos é usado como critério de sucesso?
3
38 Existe um processo formal para definir se projetos serão ou não executados, se submeterá proposta?
0
39 A organização aplica um processo formal de acompanhamento dos riscos durante a execução do projeto?
0
40 Há um procedimento de controle de riscos durante a execução do projeto? 0
41 O procedimento de controle de riscos durante a execução do projeto é aplicado? 0
42 Há um procedimento para controle e acompanhamento da execução do projeto? 2
43 O procedimento de controle e acompanhamento da execução do projeto é aplicado?
1
44 Há um procedimento para controle de mudanças de calendário do projeto? 3
45 O procedimento de controle de mudanças de calendário do projeto é aplicado? 1
46 É feita uma estimativa de problemas que poderão surgir sobre a estimativa das atividades que compõe o projeto?
1
47 É feita a coleta de informações sobre a correção das atividades que foram estimadas para o projeto?
2
48 São implementadas melhorias na estimativa de atividades dos projetos baseando-se em informações coletadas em projetos anteriores?
1
49 Há um procedimento de controle de mudanças de escopo durante a execução do projeto?
3
50 O procedimento de controle de mudanças de escopo durante a execução do 3
167
N. Pergunta
Descrição Nota (0 a 5)
projeto é aplicado?
51 É feita uma estimativa de problemas que poderão surgir sobre o escopo do projeto?
1
52 É feita a coleta de informações sobre problemas surgidos de escopo mal definido ou de mudanças de escopo?
3
53 São implementadas melhorias no planejamento de escopo e no controle de mudança de escopo dos projetos baseando-se em informações coletadas em projetos anteriores?
0
54 Há um procedimento para elaboração de relatórios de desempenho? 0
55 O relatório de desempenho é feito conforme procedimento definido durante a execução do projeto?
0
56 Há um procedimento para controle de mudanças de custos do projeto? 0
57 O procedimento de controle de mudanças de custos do projeto é aplicado? 0
58 É feita uma estimativa de problemas que poderão surgir sobre a estimativa de custos do projeto?
0
59 É feita a coleta de informações sobre problemas surgidos de custos mal definidos?
0
60 São implementadas melhorias na estimativa de custos dos projetos baseando-se em informações coletadas em projetos anteriores?
0
61 É feita a coleta de informações sobre problemas surgidos na elaboração de relatórios de desempenho?
0
62 São implementadas melhorias na elaboração de relatório de desempenho baseando-se em informações coletadas em projetos anteriores?
0
63 É feita a coleta de informações sobre a ocorrência de riscos e as respostas dadas durante a execução do projeto?
0
64 São implementadas melhorias no levantamento de riscos e no planejamento de respostas a riscos baseando-se em informações coletadas em projetos anteriores?
0
65 Há um procedimento de encerramento de projetos? 3
66 O procedimento de encerramento de projetos é aplicado? 2
67 É feita a coleta de informações sobre problemas surgidos no processo de encerramento do projeto?
0
68 São implementadas melhorias no processo de encerramento do projeto baseando-se em informações coletadas em projetos anteriores?
0
69 Há a coleta de informações de “lições aprendidas” no projeto? 1
70 As informações de “lições aprendidas” são compartilhadas pelas equipes de projetos?
1
71 As informações de “lições aprendidas” são utilizadas em novos projetos? 1
72 É realizado benchmarking para comparar o desempenho de projetos? 3
73 Há apoio da empresa para as equipes de projeto através de suporte técnico ou de um bom ambiente de trabalho?
5
168
9 APÊNDICES POR AUTOR INDIVIDUAL
9.1 DANIELE MARTINS
GESTÃO DE PESSOAS COMO DIFERENCIAL COMPETITIVO
A Gestão de Pessoas apresenta como uma importante ferramenta na busca de bons
resultados e da manutenção de empresas no mercado globalizado. Segundo Vieira (a), “além
dos clientes e dos produtos, sem dúvida alguma, os recursos humanos fazem parte dos
principais ativos das organizações. As pessoas movem as engrenagens da produtividade. O
sucesso dos projetos e também das organizações é determinado pelas atitudes profissionais
das pessoas. Um dos maiores desafios dos gerentes de projetos, sejam eles de tecnologia da
informação ou de outra natureza, é gerenciar efetivamente os recursos humanos.”.
Para gerenciar as pessoas com efetividade é necessário mudar a forma de ver os
funcionários e, consequentemente, de se relacionar com eles. Chiavenato aponta duas formas
distintas de tratar as pessoas que compõem uma empresa, como recursos produtivos ou como
parceiras. Na tabela abaixo vemos as distinções apontadas por este autor.
Tabela 1: Quadro comparativo entre recurso e parceiro. (b)
Neste quadro comparativo observamos as características de cada forma de perceber
as pessoas numa empresa. Ao conceber como recurso, torna-se necessária uma maior
intensidade de ações relacionadas ao gerenciamento para que seja obtido o desempenho
desejado para as atividades, visto que a postura dos recursos é essencialmente passiva. Já, ao
conceber os colaboradores como parceiros, como ressalta Travassos (b), “elas são
fornecedoras de conhecimento, habilidades, competências e, sobretudo, o mais importante: a
inteligência que proporciona decisões racionais e o alcance dos objetivos. Dessa forma, as
169
pessoas deixam de ser meramente recursos e passam a ser parceiras comprometidas com o
desempenho máximo de suas atribuições e com o sucesso do projeto.”
Outro fator que contribui para o gerenciamento de pessoas com efetividade é a
adoção de processos. Conforme o PMBOK® Guide, fazem parte do gerenciamento de
recursos humanos processos que viabilizem a organização e o gerenciamento da equipe
envolvida no projeto. Também destaca que a importância da atribuição de funções e
responsabilidades às pessoas que compõem a equipe para a finalização de projetos com
qualidade. E define os seguintes processos para este gerenciamento:
“9.1 Planejamento de recursos humanos – Identificação e documentação de funções, responsabilidades e relações hierárquicas do projeto, além da criação do plano de gerenciamento pessoal.9.2 Contratar ou mobilizar a equipe do projeto – Obtenção dos recursos humanos necessários para terminar o projeto.9.3 Desenvolver a equipe do projeto – Melhoria de competências e interação de membros da equipe para aprimorar o desempenho do projeto.9.4 Gerenciar a equipe do projeto – Acompanhamento do desempenho de membros da equipe, fornecimento de feedback, resolução de problemas e coordenação de mudanças para melhorar o desempenho do projeto.” (c)
Esses processos não são estáticos, interagindo entre si e com as demais áreas de
gerenciamento e abrem espaços para tornar os recursos humanos peças fundamentais para
uma empresa. Muito se tem debatido sobre o valor dos recursos humanos para as empresas e
sobre formas de transformá-los em aliados nas batalhas diárias em busca de sucesso no
mercado globalizado marcado por constantes mudanças e incertezas. E incertezas, estas que
tornaram o ambiente de trabalho fonte geradora de estresse e, consequente diminuição da
produtividade.
“Em primeiro lugar gostaria de deixar claro que nossa lista das melhores empresas para se trabalhar não é perfeita, e no tocante ao estresse é preciso admitir que são realmente poucas as organizações que são realmente boas em lidar com o mesmo. O que eu tenho visto em relação a este problema na realidade está mais ligado à sensação que as pessoas têm de não estarem com sua vida, e seu trabalho, sob algum grau de controle, do que com a competição interna propriamente dita. E é este aspecto que credencia umas poucas organizações a lidarem eficazmente com o estresse: elas possibilitam que os seus colaboradores tenham a sensação que suas vidas estão razoavelmente sob controle. A competição pode ser até muito saudável, se as pessoas sentirem que naquela organização elas têm controle sobre suas vidas. O que estressa as pessoas num ambiente competitivo é a constatação pelo indivíduo de que a
170
competição não o está levando a lugar algum, que não está gerando resultados positivos. Uma boa empresa para se trabalhar é onde você confia nas pessoas para quem você trabalha (gerentes e dirigentes), tem orgulho e gosta do que faz e gosta e confia nas pessoas com quem trabalha (senso de camaradagem).” Robert Levering (1999)
Nesta resposta dada ao Dr. Paulo Pegado em entrevista realizada durante o Segundo
Encontro de Qualidade de Vida no Trabalho, realizado na USP em 05 de Julho de 1999,
Levering mostra o terreno fértil a ser semeado – investimento no capital humano - afinal são
as pessoas que fazem a diferença para o negócio. Em outras palavras, o estímulo ao
desenvolvimento do se humano transformou-se num investimento de mão dupla, onde ganha
a empresa, que passa a contar com colaboradores mais capacitados, como também o
profissional, que adquire novas competências, sejam essas técnicas ou comportamentais.
Atualmente as organizações que entendem que o Recurso Humano é um dos mais
importantes recursos da organização se não o mais importante recurso, estão se destacando
expressivamente no âmbito do negócio que atuam ganhando posição no mercado ou
consolidando a sua fatia. Destacam se consideravelmente, pois utilizam desse recurso
aplicando os mais modernos métodos de aperfeiçoamento profissional, seleção e estímulo da
motivação, aproveitando o máximo possível do potencial que muita das vezes está ocioso nos
seus quadros de colaboradores que são a essência da organização.
Elevando-se os colaboradores da categoria de “recurso” para a de “ser” humano,
estes passam a sentir-se parte da empresa e a contribuir cada vez mais para o sucesso de
ambos – do profissional e de sua empresa.
Atuando num contexto de globalização, as empresas devem estar constantemente
atentas às mudanças e exigências do mercado, planejando estratégias, investindo – nas
pessoas e em seus processos –, analisando os riscos e as oportunidades. A cada dia é mais
essencial se antecipar às necessidades do mercado para não estar constantemente correndo
atrás de seus concorrentes.
A gestão de pessoas, quando realizada de forma consciente, torna-se uma excelente
vantagem competitiva, já que a satisfação dos colaboradores funciona como fonte de inovação
e de melhoramento contínuo. A empresa pode ter ótimas instalações, produtos úteis e uma
propaganda que marca, contudo se as pessoas que a compõe não se sentirem parte dela, seus
esforços em prol da melhoria contínua, em geral, serão insuficientes para a empresa navegar
pela acirrada batalha no mercado.
171
(a) VIEIRA, Marconi Fábio. Gerenciamento de Projetos de Tecnologia da Informação.
Rio de Janeiro: 2003.
(b) TRAVASSOS, Alexandre. Recursos Humanos: como gerenciá-los em projetos? Ver.
Mundo Project Management. Ano 4, nº 21.
(c) CHIAVENATO, Idalberto. Gestão de Pessoas: o novo papel dos recursos humanos nas
organizações. Rio de Janeiro: 1999.
172
9.2 FERNANDO REZENDE CELESTINO
COMO O CMM PODE COMPLEMENTAR AS BOAS PRÁTICAS DO PMBOK EM
PROJETOS DE SOFTWARE: ÁREAS DE ESCOPO, TEMPO E CUSTO.
Comparando o modelo de maturidade OPM3, apoiado nas boas práticas do PMBOK,
com o modelo de maturidade CMM, com suas próprias boas práticas, observamos que os
mesmos podem se complementar de maneira eficiente para auxiliar uma empresa que realiza
projetos de software a aumentar a sua maturidade. O PMBOK trazendo as práticas para
gerenciamento de projetos independente da sua natureza, e o CMM, criado pelo SEI
(Software Engineering Institute), ajudando a concretizar as práticas indicadas pelo PMBOK
de maneira eficiente para projetos de software.
A figura abaixo mostra o relacionamento entre as áreas de conhecimento do PMBOK
e as áreas de processo do CMM:
Figura 1 Fonte [b]
173
O presente estudo pretende demonstrar algumas formas pelas a área de conhecimento
de Gerência de Escopo do PMBOK pode ser complementada pelas áreas de processo de
Gerência de Requisitos do CMM.
Visão de Gerenciamento de Projetos dentro do CMM
O CMM for Development contém uma área de processo específica para
Gerenciamento de Projetos, a qual indica ferramentas e boas práticas que são as mesmas ou
muito similares às do PMBOK. No entanto, no CMM for Development, essas boas práticas de
projetos estão explicitamente relacionadas a boas práticas de outras áreas de processos,
agrupadas no que é chamado de “Áreas de Suporte e Engenharia” (Engineering and Support
Áreas). Nestas áreas estão as práticas específicas de software.
A figura 2 mostra as áreas de processo de Gerenciamento de Projetos do CMM,
como elas se relacionam, e a ligação com as áreas de suporte e engenharia.
Figura 2 Fonte [a]
174
Os processos de suporte dizem respeito a garantia de qualidade, controle de
mudanças e métricas, como mostrado na figura 3.
Figura 3 Fonte [a]
Os processos de engenharia englobam parte dos processos de definição de escopo
(Requisitos Funcionais e técnicos), e processos de verificação do escopo, como mostrado na
figura 4.
Figura 4 Fonte [a]
Sugestão de uso da área de processo de Gerência de Requisitos do SEI-CMM para
complementar o processo de Definição de Escopo do PMBOK.
175
Os processos de definição de escopo e desenvolvimento de requisitos estão
interligados. Isto se deve ao fato de que o escopo de projetos de software é delineado
principalmente pelos seus requisitos funcionais (Funcionalidade desejada pelo cliente) e não
funcionais (Performance, segurança e outros). [a] [b].
Os projetos de desenvolvimento de software, pelo modelo clássico (Seqüencial), são
divididos nas fases de Análise, Design, Codificação e Testes. Em outras abordagens mais
modernas, como os modelos de prototipação, RAD, espiral, e Extreme Programming, tais
fases também existem mas são repetidas em ciclos sucessivos para garantir melhor
entendimento geral sobre o produto a produzir.[c].
Segundo Pressman [c], O levantamento de requisitos é sempre o primeiro passo em
qualquer atividade de análise de um software. Esta atividade pode ser realizada através de
reuniões entre o cliente e os desenvolvedores/analistas para definir os requisitos básicos do
sistema e do software. Baseado nestes requisitos, o engenheiro de software (Analista), pode
criar um conjunto de cenários, cada qual identificando um uso hipotético do sistema a ser
construído. Estes cenários, geralmente chamados de Use Cases, provêem uma descrição de
como o sistema será usado. [c].
Grande parte das empresas de desenvolvimento de software utiliza a análise
orientada a objetos, na qual a especificação de requisitos através de use cases é amplamente
difundida.
Lembrando que os requisitos do sistema em um projeto de software representam o
escopo do cliente. No entanto, o escopo do projeto não se resume ao escopo do cliente. É
preciso gerar outros produtos e serviços, tais como: treinamentos para equipe do projeto,
plano do gerenciamento do projeto, relatórios de desempenho, contratos, etc.. [e].
Como ferramenta para definir e especificar o escopo do projeto, ambos os guias,
CMM e PMBOK indicam a WBS (Work Breakdown Structure), e um dicionário da WBS.
Estes artefatos deverão revistos e refinados até que o planejamento do projeto possa ser
completado. [e].
176
Segundo o CMM, o desenvolvimento de uma WBS divide o projeto geral em um
conjunto de componentes gerenciáveis interconectados. Tipicamente, a WBS é uma estrutura
orientada a produto que provê um esquema para identificar e organizar as unidades lógicas de
trabalho a serem gerenciadas, chamadas “Work Packages” ou Pacotes de Trabalho. A WBS
provê uma referência, e mecanismo organizacional para atribuir esforço, cronograma e
atribuir responsabilidades, e é usada como o framework para planejar, organizar e controlar o
trabalho feito no projeto. Alguns projetos utilizam o termo “WBS de contrato” para se referir
à parte da WBS que é inserida no contrato (Algumas vezes, toda a WBS). Nem todos os
projetos tem uma WBS de contrato (Ex: Projetos desenvolvidos com fundos internos da
organização).
Para representar o escopo do cliente (Funcionalidades desejadas), a metodologia ágil
de gerenciamento de projetos SCRUM recomenda uma estrutura chamada FBS (Functional
Breakdown Structure) [d]. Neste caso sugere-se usar a FBS como um ramo da WBS completa
do projeto, contemplando desta forma o escopo do cliente e os demais entregáveis
necessários, como os de gerenciamento. Os pacotes da FBS serão os use cases, podendo os
mesmos ter subordinados componentes, e em seguida elementos de design, conforme o nível
de detalhamento desejado para o projeto específico, conforme sua complexidade.
O CMM indica como sub-práticas à prática de definição de escopo na WBS:
1 – Desenvolver a WBS com base na arquitetura do sistema
2 – Identificar os work packages em nível de detalhe suficiente para dar estimativas de
esforço e cronograma, bem como atribuir responsabilidades.
3 – Levar em conta a re-utilização de componentes de software (Identificar produtos de
trabalho que serão reutilizados).
O processo de definição de escopo do CMM: Desenvolvimento de Requisitos
177
O objetivo do Requirements Development (RD) é produzir e analizar requisitos do
cliente, do produto e de componentes do produto. Neste processo, o CMM for Development
procura adequar as práticas consagradas para software no que diz respeito a requisitos, com
projetos para criação de produtos de qualquer natureza, não somente software.
Esta área de processo do CMM descreve 3 tipos de requisitos: Requisitos do cliente,
do produto e de componentes do produto. Em conjunto, estes requisitos endereçam as
necessidades dos stakeholders relevantes, incluindo aqueles pertinentes a várias fases do ciclo
de vida do produto (Ex: Critérios de aceitação de testes), e atributos do produto (Ex:
Segurança, confiabilidade, e manutenibilidade). Requisitos também endereçam restrições
causadas pela seleção de determinadas soluções de design. (Ex: Integração de produtos
comerciais prontos (off-the-shelf).
Todo projeto de desenvolvimento tem requisitos. No caso de um projeto focado em
atividades de manutenção, as mudanças ao produto ou aos componentes do produto são
baseadas em mudanças nos requisitos existentes (Que deram origem ao produto existente), ao
design ou implementação do mesmo.
Requisitos são a base para o design. O desenvolvimento de requisitos inclui as
seguintes atividades:
• Esclarecimento, análise, validação e comunicação de necessidades, expectativas e
restrições do cliente para obter os requisitos do cliente que constituem um
entendimento do que é necessário para satisfazer os stakeholders.
• Relacionar e coordenar necessidades dos stakeholders
• Desenvolver os requisitos de ciclo de vida do produto
• Estabelecer os requisitos do cliente (Funcionalidades esperadas do software).
• Estabelecer os requisitos iniciais do produto e dos componentes do produto de forma
consistente com os requisitos do cliente. (Arquitetura e componentes reutilizáveis).
178
Segundo o CMM, o desenvolvimento de requisitos deve endereçar todos os
requisitos do cliente, e não só requisitos de nível do produto, porque o cliente sempre pode
prover requisitos específicos para o design.
Os requisitos do cliente são refinados em requisitos do produto e dos componentes
do produto. Além dos requisitos do cliente, os requisitos de produto e de componente do
produto são derivados das soluções de design adotadas. Através dos diversos processos do
CMM, onde se refere a produto e componente do produto, o significado desejado engloba
serviços e seus componentes.
A área de processo de desenvolvimento de requisitos inclui 3 objetivos específicos:
1 – Desenvolver requisitos de cliente: Definir um conjunto de requisitos do cliente para usar
no desenvolvimento dos requisitos de produto.
2 – Desenvolver requisitos do Produto: Definir um conjunto de requisitos do produto ou dos
componentes do produto a serem usados no design do produto e seus componentes.
3 – Analisar e Validar Requisitos: Análise de requisitos do cliente, do produto e dos
componentes para definir, derivar e entender os requisitos. As práticas deste objetivo servem
de suporte aos dois primeiros.
Os processos associados ao desenvolvimento de requisitos podem interagir
recursivamente com os processos de solução técnica.
Análises são utilizadas para entender, definir e selecionar os requisitos em todos os
níveis, com base em alternativas concorrentes. Esta análise inclui:
- Análise das necessidades e requisitos para cada fase do ciclo de vida do produto, incluindo
necessidades de stakeholders relevantes, ambiente operacional, e fatores que reflitam
expectativas e satisfação geral do cliente e dos usuários finais, como segurança e economia.
- Desenvolvimento de um conceito operacional
- Definição de todas as funcionalidades requeridas.
179
A definição das funcionalidades, também chamada de Análise Funcional, não deve
ser confundida com análise estruturada em desenvolvimento de software, ou presumir um
design orientado a funcionalidade. Em design de software orientado a objetos, Análise
Funcional diz respeito a definir o que é chamado neste contexto de “Serviços” ou “Métodos”.
A definição de funções, seu agrupamento lógico e a associação entre as mesmas com
requisitos é referido como “Arquitetura Funcional”.
A Análise ocorre recursivamente, em níveis sucessivamente mais detalhados da
arquitetura do produto até que detalhamento suficiente esteja disponível para possibilitar
design, aquisição e testes do produto. Como resultado da análise de requisitos e do conceito
operacional (Incluindo funcionalidade, suporte e manutenção), o conceito do produto produz
mais requisitos derivados, incluindo consideração do seguinte:
- Requisitos de vários tipos
- Limitações Tecnológicas
- Custo e “drivers” de custo
- Restrições de tempo e cronograma
- Riscos
- Problemas e dificuldades implícitos mas não informados explicitamente pelo cliente ou
usuário final.
Sugestão de uso da área de processo de Gerência de Requisitos do SEI-CMM para
complementar o processo de Verificação de Escopo do PMBOK.
Estando o escopo bem definido e especificado, deve ser definido o critério de
aceitação para cada item, conforme indicado pelo PMBOK. Como critério de aceitação para
os itens funcionais, os use cases, geralmente são utilizados testes de aceitação baseados nos
cenários dos use cases [c]. Tais testes devem ser executados por uma equipe do cliente. Os
testes são especificados através de documentos de casos de teste, ou test cases, que definem os
passos que deverão ser executados no sistema para verificar que o mesmo desempenha todas
as funcionalidades acordadas conforme especificado.
180
Conclusão
Estudando o guia CMM for Development, observa-se claramente suas raízes comuns
com o PMBOK, e pode-se tirar proveito do fato do primeiro detalhar mais a maneira de
aplicação das boas práticas a projetos de software, tendo em vista sua origem em projetos
desta natureza (Engenharia de Software).
[a] - CMMI® for Development, Version 1.2, Carnegie Mellon Software Engineering Institute
(SEI)
[b] - Gerência de Projetos de Software CMM & PMBOK, José Ignácio Jaeger Neto, Fernanda
Schmidt Bocoli – PROCERGS – (http://www.scribd.com/doc/4672356/Gerencia-Projetos-
Software-CMM-PMBOK)
[c] – Software Engineering, A Practitioner´s Approach, Fourth Edition, Roger s. Pressman,
Ph.d, McGraw-Hill, 1997.
[d] - PMP vs. Scrum Master, Karen Little, PMP, (http://mydlc.com/pmi-
mn/PRES/2008C11_PMPvsScrumMaster.pdf)
[e] – Metodologia de Gerenciamento de Projetos – METHODWARE, Carlos Magno da Silva
Xavier, Flavio Ribeiro Vivacqua, Otualp Sarmento de Macedo, Luiz Fernando da Silva
Xavier.
[f] – Fundamentos do Gerenciamento de Projetos, André Bittencourt do Valle, Carlos Alberto
Pereira Soares, José Finocchio Jr., Lincoln de Souza Firmino da Silva, FGV Editora.
181
9.3 JOÃO OSWALDO MAZUR
O uso de metodologias de software e gerenciamento de projetos no
aprimoramento de pequenas empresas de desenvolvimento de software
INTRODUÇÃO
Pequenas empresas de desenvolvimento de software encontram diversos problemas
na concepção dos seus produtos, desde o detalhamento da idéia e das necessidades, passando
pelo processo produtivo, até a entrega, onde não consegue um produto estável e sem defeitos.
Muitas vezes estas empresas são criadas por profissionais ainda em formação acadêmica ou
com pouca experiência de mercado e acabam executando o processo de criação do software
de maneira empírica e intuitiva, gastando pouco tempo no planejamento e organização e
partindo diretamente para a programação. Em geral os resultados destas empresas são:
prejuízos, desgaste dos “sócios-programadores” e a insatisfação do cliente, o que pode
resultar no não crescimento ou até o fechamento da empresa.
Dentro deste contexto torna-se necessário a sugestão de uma metodologia mínima de
desenvolvimento de software e de gerenciamento de projetos, que auxilie na obtenção de
sucesso sem que percam a vantagem competitiva do custo inferior e agilidade, quando
comparadas às grandes corporações.
A METODOLOGIA DE DESENVOLVIMENTO DE SOFTWARE
As exigências para o desenvolvimento de software são, em geral, interpretadas como
poucas e simples: uma idéia, um computador e uma pessoa com algum conhecimento na
linguagem de programação do computador. Porém nesta aparente simplicidade, tratada até
como um desenvolvimento artesanal, reside o principio de sistemas problemáticos, de baixo
desempenho, com bugs e que não atende as necessidades do cliente. A obtenção de sistemas
de software de qualidade exige conhecimentos técnicos específicos, equipe treinada e a
existência de procedimentos e processos definidos e seguidos.
O software pode ser compreendido como sistema que deve desempenhar o controle e
execução de diversas ações a partir de determinadas entradas e resultando e uma série de
saídas. Para o cliente comprador do software a interpretação pode ser a de produto que ao
atender determinados requisitos automatiza, simplifica e controla determinados processos. Em
182
ambas as definições ficam claro que um dos fatores para o sucesso do software é atingir as
necessidades e expectativas do cliente englobando os requisitos mínimos do processo a ser
automatizado. Ou seja, é necessário definir um processo de gerenciamento de requisitos.
O processo de gerenciamento de requisitos é o detalhamento do escopo preliminar,
ou seja, o detalhamento das necessidades do cliente. Este processo pode ser divido em várias
atividades: compreensão do domínio, identificação das partes interessadas, coleta,
identificação e análise de problemas. Na compreensão do domínio é muito importante para o
analista compreender como a organização e o projeto se inserem para proporcionar uma
comunicação eficiente entre o ele e as partes interessadas. Na identificação das partes
interessadas concentram-se esforço em levantar e entender os utilizadores do sistema. A
coleta consiste na obtenção com o cliente dos requisitos (funcionais e não-funcionais)
pretendidos para o sistema, assim como todas as regras de negócio. Já na identificação e
análise de problemas, os problemas precisam ser identificados e soluções devem ser propostas
em conjunto com as partes interessadas. O levantamento de requisitos é um processo de
conversa com o cliente para entender o que ele deseja e espera do sistema e seus resultados.
Tão importante quanto levantar e entender os requisitos do sistema é documentá-los de forma
organizada, criando um documento de especificação de requisitos. Os requisitos podem ser
funcionais que descrevem as funcionalidades que se espera do sistema, ou seja, é aquilo que o
utilizador espera quando for utilizar o sistema. Os requisitos não-funcionais referem-se a
restrições nas quais o sistema deve operar ou propriedades emergentes do sistema.
O software como resultado, ou seja, como um entregável para o cliente, precisa que
os requisitos de funcionamento sejam transformados em linguagem de programação de
computadores. Para esta transformação é necessário que todos os requisitos levantados sejam
analisados e interpretados, resultando no planejamento técnico e design do sistema. Com a
análise em mão os programadores podem então desenvolver suas atividades de programação.
O produto software também precisa ser validado antes da sua conclusão e publicação
em ambiente de produção. As etapas de validação começam nos pequenos itens ou pacotes
desenvolvidos, onde são efetuados os chamados testes unitários e têm por objetivo testar telas
ou pequenas unidades do sistema. A validação dá seqüência à medida que as diversas porções
do software são conectadas e torna-se necessário certificar que a integração está efetiva e de
acordo com o esperado, são os chamados testes integrados. Os testes integrados finalizam
quando é possível testar o software como um todo. Após a validação por parte da empresa de
183
desenvolvimento é necessário que o cliente também valide o sistema, para certificar que
atende as suas necessidades e expectativas, esta fase pode ser chamada de homologação.
Estas três atividades macro definidas acima: engenharia de requisitos,
implementação do software e validação do sistema, constituem a metodologia de
desenvolvimento de software. As metodologias podem ser divididas em duas nominações:
tradicionais e ágeis (Charete, R, (2001). A metodologia nominada tradicional, ou clássica, ou
ainda seqüencial, é um modelo em que existe uma seqüência onde cada etapa tem
dependência do termino da etapa anterior (Pressman, 2001). De uma forma geral fazem parte
do modelo tradicional as etapas de definição de requisitos, projeto do software,
implementação e testes unitários, integração e teste integrados, homologação e implantação.
As metodologias ágeis começaram a tornar populares no início do Século XXI, com o
surgimento da Extreme Programing, ou XP e posteriormente o Scrum. As metodologias ágeis
têm em comum: constantes iterações entre equipe de desenvolvimento e cliente, ao invés de
processos e ferramentas; entrega de software executável ao invés de documentação de análise
e protótipo; colaboração do cliente ao invés de negociação de contratos; respostas rápidas a
mudanças ao invés da criação de planos e análises (Agile Manifesto, 2009). Tem-se por
princípio que o cliente estará sempre disponível para verificações e respostas às dúvidas, e
que o processo de desenvolvimento será em etapas, com análise, desenvolvimento e entrega
de pequenas porções do software, que ao final constituirá um todo.
A METODOLOGIA DE GERENCIAMENTO DE PROJETOS
Um projeto pode ser definido como um empreendimento não repetitivo caracterizado
por uma seqüência clara e lógica de eventos, com início e fim, que se destina a atingir
um objetivo claro, definido e único, sendo conduzido por pessoas dentro de parâmetros
predefinidos de tempo, custo, recursos envolvidos e qualidade (PMI, 2004). Desta forma o
processo completo de desenvolvimento de software pode ser classificado como um projeto e,
dentro deste contexto, necessita que as boas práticas de gerenciamento de projetos sejam
utilizadas e uma metodologia de gerenciamento de projetos seja adotada.
O gerenciamento de projetos é importante por auxiliar no sucesso do mesmo
controlando variáveis como: escopo, tempo, custo e qualidade. Uma metodologia é um
conjunto de regras e procedimentos de como iniciar, planejar, executar, controlar e encerrar
um projeto. Uma metodologia adotada pelo mercado é a sugerida pelo PMI (Project
184
Management Institute), instituição internacional sem fins lucrativos que agrupa profissionais
da área de Gerência de Projetos, no seu PMBoK Guide (Project Management Body Of
Knowledge).
O PMBoK reúne uma série de processos e procedimentos referentes ao
gerenciamento de projetos e estão divididos em 9 áreas de conhecimento: gerenciamento de
integração do projeto, gerenciamento do escopo do projeto, gerenciamento de tempo do
projeto, gerenciamento de custos do projeto, gerenciamento da qualidade do projeto,
gerenciamento de recursos humanos do projeto, gerenciamento das comunicações do projeto,
gerenciamento de riscos do projeto, gerenciamento de aquisições do projeto.
O Gerenciamento de integração do projeto descreve os processos e as atividades que
integram os diversos elementos do gerenciamento de projetos, ou seja, as demais áreas de
conhecimento. Gerenciamento do escopo do projeto descreve os processos e atividades
envolvidos no controle do trabalho necessário para a conclusão do projeto. O Gerenciamento
de tempo do projeto, descreve os processos relativos a condução, controle e conclusão do
projeto dentro dos prazos pré-estabelecidos. O Gerenciamento de custos do projeto descreve
os processos de planejamento, estimativa, orçamentação e controle de custos. Gerenciamento
da qualidade do projeto descreve os processos envolvidos para atingir os níveis garantia do
projeto necessário à satisfação do cliente. O Gerenciamento de recursos humanos do projeto
descreve os processos necessários ao gerenciamento da equipe do projeto. O Gerenciamento
das comunicações do projeto descreve os processos relativos à geração, coleta, divulgação e
destinação das informações do projeto. O Gerenciamento de riscos do projeto descreve os
processos relativos à análise e controle dos riscos do projeto. O Gerenciamento de aquisições
do projeto descreve os processos de compra ou aquisição de produtos, serviços ou resultados
externos ao projeto, além da gestão dos contratos. A figura 1 apresenta uma visão geral das
áreas de conhecimento em gerenciamento de projetos e os seus processos.
185
Figura 1 - Visão geral das áreas de conhecimento em gerenciamento de projetos e os
processos de gerenciamento de projetos. Fonte: PMI, PMBoK, 2004.
CONTEXTO
Conforme citado anteriormente as pequenas empresas de desenvolvimento de
software, em geral, são fundadas com bons conhecimentos técnicos e um espírito
empreendedor, porém constituídas por profissionais ainda em formação acadêmica ou com
pouca experiência de mercado. Assim o processo de criação do software utilizado é empírico
e intuitivo, focada em muito trabalho e soluções, mas com pouco planejamento e controle.
Ainda dentro deste contexto existem empresas que conseguem relativo sucesso e
alguma fatia do mercado, conseguindo novos clientes e vendendo novos projetos. Porém ao
serem efetivados dentro do mesmo processo caótico acabam multiplicando os problemas,
186
gerando prejuízos, desgastando os “sócios-programadores” e causando a insatisfação do
cliente. E esta situação pode ainda ser agravada com a entrada de novos programadores que
podem introduzir ainda a visão pessoal do desenvolvimento de software. A falta de um
processo definido pode comprometer o crescimento da empresa, se não por vezes causar o seu
fechamento, ainda que constituída por pessoas capacitadas.
Apesar dos problemas encontrados estas pequenas empresas possuem muitas
características positivas, como o engajamento da equipe, que por muitas vezes são os sócios
do negócio, e a sua agilidade e custo baixo, pois não possuem muitas formalidades e processo
burocráticos característicos das grandes empresas e corporações. Assim quando da escolha
das metodologias de desenvolvimento de software e gerenciamento de projetos deve-se ter em
mente que elas devem proporcionar a geração de sistemas de qualidade e com lucratividade,
permitindo o crescimento e evolução da empresa, sem a criação de um processo complexo e
dispendioso que venha a reduzir a agilidade e aumentar seus custos.
METODOLOGIA SUGERIDA
No intuito de auxiliar as pequenas empresas de desenvolvimento de software segue
abaixo uma sugestão de escolha de metodologias e quais processos implantarem, tanto para o
desenvolvimento de software quanto para o gerenciamento do projeto.
METODOLOGIA DE DESENVOLVIMENTO DE SOFTWARE
A recomendação para pequenas empresas de software que não possuírem uma
metodologia definida é a metodologia de desenvolvimento tradicional. Pela suas
características de certa forma intuitiva e amplamente adotada e aceita pelo mercado torna-se
uma boa escolha inicial. Dentro da metodologia quatro processos básicos precisam ser
definidos e implantados: levantamento de requisitos, análise dos requisitos, desenvolvimento
do software e validação do software.
O levantamento de requisitos é o processo de detalhamento do escopo preliminar, ou
seja, detalhamento das necessidades do cliente. Este processo pode ser divido em várias
atividades: compreensão do domínio, identificação das partes interessadas, coleta,
identificação e análise de problemas. O levantamento de requisitos é um processo de conversa
com o cliente para entender o que ele deseja e espera do sistema e seus resultados, para isto
187
deve-se fazer reuniões, entrevistas e questionários enquanto existirem pontos não
esclarecidos.
Tão importante quanto levantar e entender os requisitos do sistema é documentá-los
de forma organizada, criando um documento de especificação de requisitos. Existem vários
padrões e formas de documentação que se encaixam melhor a cada tipo de sistema e empresa,
não sendo possível identificar o modelo ideal, porém recomenda-se a utilização de linguagem
simples, concisa e não técnica para que possa se comunicar de forma adequada ao leitor leigo.
Para auxiliar o entendimento mútuo dos requisitos do sistema pode ser necessária a
utilização de prototipagem. A prototipagem consiste de uma versão inicial do sistema,
baseada nos requisitos já bem definidos ou ainda superficiais, que pode ajudar a encontrar
desde cedo falhas que através da comunicação verbal não são tão facilmente identificáveis. A
prototipagem consiste da criação das principais telas do sistema sem ou com poucas
funcionalidades, para que possa proporcionar para o cliente uma idéia visual de como a
analista interpretou as suas necessidades.
Ao final do levantamento de requisitos é necessário validar a documentação e
protótipo com o cliente, para que seja certificado de que o analista conseguiu compreender e
extrair do cliente as suas necessidades e expectativas para o sistema. Pode ser necessário um
aceite formal e documentado da finalização da fase de requisitos. Também é comum, durante
a fase de levantamento de requisitos, que surjam novos itens não previstos na declaração
inicial do escopo, o que pode necessitar de renegociação propostas e valores ou a eliminação
dos itens fora do escopo.
Finalizada e aprovada a fase de levantamento de requisitos inicia-se a de análise de
sistemas, que é a atividade de realização de estudos dos requisitos e processos a fim de
encontrar o melhor caminho racional para que a informação possa ser processada. Na fase de
análise faz-se a modelagem do banco de dados e do sistema. A modelagem de software é a
atividade de construir modelos que expliquem as características ou o comportamento de um
software ou de um sistema de software, de forma que seja possível para os programadores
executarem suas atividades de desenvolvimento do sistema. Para a modelagem do sistema
uma opção difundida no mercado é a Unified Modeling Language (UML), que é uma meta-
linguagem que permite que desenvolvedores visualizem os produtos de seu trabalho em
diagramas padronizados.
188
Para o desenvolvimento do software o processo depende da linguagem de
programação escolhida, dos frameworks e design patterns adotados, assim não é possível a
sugestão da melhor opção. A recomendação é que cada programador envolvido no projeto
tenha conhecimento pleno do escopo do projeto e dos requisitos e saiba exatamente suas
atividades, atribuições e responsabilidades dentro do projeto, assim como o conhecimento
técnico específico.
Para a fase da validação do software cada programador deve ser o responsável direto
pelas partes a ele designadas devendo executar os testes unitários e testes integrados. Para os
testes integrados do sistema pode ser designado um profissional específico para isto que deve
garantir que o sistema desenvolvido esteja em conformidade com os requisitos levantados e
que esteja livre de problemas ou bugs, para garantir a qualidade do software. A fase de
validação do cliente ou fase de homologação, deverá ser executada pelo cliente antes da
publicação final do sistema. Na etapa de homologação o cliente deve confirmar que o
software atende aos seus requisitos e expectativas, assim como se o fluxo e funcionamento
estão corretos. É importante elaborar um processo de registro dos problemas e designação dos
responsáveis pela sua correção.
Ainda para a fase da validação do software, no processo de homologação do sistema,
uma boa prática é trabalhar com entregas parciais ou iterações. Nas iterações é possível
apresentar para o cliente uma parte do sistema já funcionando para a sua avaliação. Com este
procedimento é possível passar para o cliente um status de como está o andamento do projeto,
assim como para que sejam identificados solicitações de alterações ou melhorias.
METODOLOGIA DE GERENCIAMENTO DE PROJETOS
Gerenciar um projeto é atuar de forma a atingir os objetivos propostos dentro de
parâmetros de qualidade determinados, obedecendo a um planejamento prévio de prazos e
custos. O gerente de projetos é o responsável por garantir que ele e sua equipe atinjam o
sucesso do projeto dentro da tripla restrição de escopo, tempo e custo, entregando um produto
ou serviço com qualidade.
A recomendação de metodologia a ser seguida é a proposta pelo PMI, porém ela não
precisa ser aplicada na sua totalidade, e sim nos processos e melhores práticas que melhor se
encaixam a empresa e ao projeto, de forma a permitir planejamento e melhor controle, porém
sem criar um processo oneroso em tempos de custo e tempo.
189
GERENCIAMENTO DE ESCOPO
Segundo o PMBoK o “O gerenciamento do escopo do projeto inclui os processos
necessários para garantir que o projeto inclua todo o trabalho necessário, e somente ele, para
terminar o projeto com sucesso” (PMI, 2004, pg. 103). O escopo do projeto é todo o trabalho
que deve ser realizado para se obter um produto ou serviço.
O início da definição do escopo é concebido antes do início do projeto, ainda na fase
de apresentação de propostas. Nesta etapa deve-se criar a Declaração Preliminar de Escopo,
que deve ter o escopo macro, as premissas e restrições básicas do software que vai ser
entregue. Um conceito importante sobre escopo é divisão em escopo do produto e escopo do
projeto. O escopo do produto define as características e funções que descrevem um
produto,serviço ou resultado. O escopo do projeto é o trabalho que precisa ser realizado para
entregar um produto, serviço ou resultado com as características e funções especificadas
(PMI, 2004). Assim escopo do projeto é o que o cliente espera do software e escopo do
projeto é todo o trabalho necessário para o desenvolvimento do software. Assim a declaração
de escopo deve conter o escopo do projeto, pois o escopo inicial bem definido é o primeiro
passo para a estimativa de prazos e custos.
O escopo deve ser representado na forma da Estrutura Analítica de Trabalho. A EAP
é “é uma decomposição hierárquica orientada à entrega do trabalho a ser executado pela
equipe do projeto, para atingir os objetivos do projeto e criar as entregas necessárias” (PMI,
2004, pg. 112). A figura 2 mostra um exemplo de EAP. Cada um dos pacotes de trabalho
podem ser mais bem explicados e especificados em um documento chamado dicionário da
EAP. A medida que o projeto for transcorrendo o escopo deve ser sempre atualizado a cada
solicitação de alteração solicitada e aprovada.
190
Figura 2 – exemplo de EAP. Fonte: autor.
GERENCIAMENTO DOS RECURSOS HUMANOS
Todos os envolvidos no projeto são os "stakeholders". Nesse grupo estão não apenas
os membros da equipe, mas também os clientes e fornecedores envolvidos. É importante que
o gerente do projeto conheça os interesses de todos os envolvidos, principalmente de quem
vai compor a equipe de desenvolvimento, sabendo de suas qualidades técnicas e de
relacionamento, para saber se pode alocar na equipe e o quanto está disposto a colaborar.
Nesse momento, é importante formar uma equipe com competência diversificada e com
experiência nas áreas de atuação do projeto.
GERENCIAMENTO DOS CUSTOS
O custo do projeto é uma conseqüência direta do processo de desenvolvimento e do
escopo determinado pelo cliente. Para a orçamentação do projeto utiliza-se a EAP e o
processo bottom-up, ou seja, orçar o custo de cada pacote de trabalho do escopo do projeto e
“subindo” na EAP vai-se somando os custos de cada item até obter o custo total do projeto.
CRONOGRAMA
O desenvolvimento do cronograma depende de vários fatores, sendo preponderante o
escopo, a equipe alocada e as limitações impostas pelo projeto e cliente. A primeira
informação importante é levantar os principais marcos ou milestones do projeto, pois elas são
os objetivos a serem atingidos em termos de prazos. Os principais marcos são: início do
projeto, início da análise, início do desenvolvimento, início da homologação e fim do projeto.
191
Com o escopo definido e os principais marcos precisa-se decompor os pacotes de
trabalhos em atividades. Para cada atividade é necessário estimar a duração. Para a estimativa
de tempo de execução é importante envolver quem está escalado para executar o trabalho. Ao
mesmo tempo em que essa pessoa é quem melhor sabe quanto tempo precisará, ela estará se
comprometendo com um prazo para a sua execução. Com as atividades levantadas é preciso
seqüenciá-las e alocá-las para os membros da equipe de acordo com as atribuições técnicas da
atividade e do recurso. Neste ponto é importante utilizar uma ferramenta para auxiliar no
seqüenciamento, como o Microsoft Project.
COMUNICAÇÃO
A comunicação é talvez o fator crítico de sucesso do projeto em que menos se dá
ênfase. É importante que todas as informações necessárias a execução do projeto estejam
acessíveis a todos os envolvidos. A primeira relação de comunicação que deve ser
estabelecida é com o cliente, para que se tenha um canal de duas vias, onde seja possível
coletar todas as informações do projeto, desde o levantamento dos requisitos até retirada de
dúvidas.
Outro canal importante de comunicação é com a equipe do projeto, é necessário
estabelecer procedimentos, documentos e relatórios que permitam que todas as informações
sobre escopo do projeto estejam claras para todos. Tão importante quanto levantar
corretamente os requisitos é repassá-los a quem vai programá-los. Outra informação que
precisa ser divulgada é a atribuição das responsabilidades e atividades alocadas a cada
membro da equipe. A divulgação do cronograma é de importância semelhante a sua
elaboração, pois cada programador e envolvido precisa saber o que deve ser feito e quando.
Este canal também precisa ser de duas vias, permitindo que o gerente possa ter acesso ao
programador e que o programador tenha acesso ao gerente de projetos.
ACOMPANHAMENTO E INTEGRAÇÃO
Para o gerente de projetos outra atribuição de grande importância no projeto, além do
planejamento, é a orientação e controle. A orientação e controle são as ações adequadas para
que o projeto seja realizado de acordo com o planejado, atingindo os objetivos de forma a
respeitar as limitações de custo e tempo. O controle do projeto deve ser executado em todas as
etapas do processo, desde a inicialização até a sua conclusão, acompanhando com freqüência
192
o avanço do projeto, e agindo de forma a controlar situações não previstas ou fora do
planejado. O cronograma deve ser atualizado junto com a equipe de acordo com as conclusões
e avanços do projeto e relatórios de progresso devem ser emitidos.
Também deve ser criado um processo para o recebimento, avaliação e validação das
solicitações de mudança. Estabelecer quem pode solicitar, como deve solicitar, como deve ser
registrado e analisado, qual o processo de aprovação e como replicar esta alteração no
cronograma e divulgar para a equipe.
MELHORIAS CONTÍNUAS NO GERENCIAMENTO
À medida que a empresa for avançando e ganhando experiência é necessário avançar
nos processos de controle do projeto. A metodologia aqui sugeria é básica para o controle de
escopo, tempo, custo e qualidade do projeto, mas é necessário aprimorá-los e introduzir
controle a outras áreas. Os avanços sugeridos são:
• Controle de custos, tempo e escopo através do EVA: A Análise do Valor Agregado,
ou Earned Value Analysis, é uma análise integrada do escopo, prazos e custos do
projeto, permitindo verificar atrasos ou adiantamentos do cronograma, identificar
extrapolações do orçamento, medir a eficiência do uso do tempo e dos recursos, além
de possibilitar inferências sobre estimativas de conclusão e custo do projeto. É uma
técnica que permite esclarecer onde o projeto está, em termos de tempo, escopo e
custo, e onde deveria estar.
• Gerenciar os riscos do projeto: Consiste em levantar e desenvolver uma lista de
fatores de risco e um plano para lidar com eles.
• Melhore a comunicação: A comunicação pode ser sempre melhorada.
• Desenvolva as habilidades gerenciais: Segundo Barcauí, “o conhecimento técnico, do
negócio e a própria formação acadêmica eram considerados pontos fundamentais para
a boa escolha de um gerente. Mais recentemente, outras características passaram a ser
consideradas e valorizadas. Habilidades antes consideradas como desejáveis, passam a
assumir um outro grau de importância. São elas: relacionamento interpessoal, gestão
de conflitos, inteligência emocional, liderança, comunicação, negociação, coaching
etc.” (Barcauí, 2002, pg. 35). Assim tão importante quanto o conhecimento técnico
são as habilidades de lidar com gente.
193
CONCLUSÃO
O objetivo deste ensaio não é estabelecer uma consultoria ou procedimento para a
melhoria do processo de desenvolvimento de software em empresas de pequeno porte, mas
sim para esclarecer que o processo precisa e deve ser melhorado. Estabelecer processos para o
desenvolvimento de software e para a gerência de projetos, desde que adotados com
sabedoria, possibilita uma maior eficiência da empresa e não cria uma burocratização
desnecessária. É preciso ter em mente que o custo e tempo para corrigir tende a ser sempre
maior que o custo de planejar.
BIBLIOGRAFIA
Agile Manifesto Disponível em http://agilemanifesto.org/, acessado em 1 de março de 2009
Charette, R. Fair Fight? Agile Versus Heavy Methodologies, Cutter Consor-tium E-project
Management Advisory Service, 2001.
Pressman, R. Engenharia de Software. McGraw-Hill, 2001
PMI. Project Management Body of Knowledge (PMBoK). Project Management Institute. Newton Square, PA. EUA, 2004.
BARCAUI, André. Gerência de Projetos Arte ou Liderança?. Revista Mundo PM, n.09, ano2, jun/jul.2006.
194
9.4 MARCELO STIVAL
GERENCIAMENTO DE COMUNICAÇÃO EM PROJETOS DE PEQUENO
PORTE
Após a avaliação das melhores práticas do OPM3 relacionadas à área de
gerenciamento de comunicação, conclui-se que nem todas as iniciativas são, em um curto
prazo, ideais para serem aplicadas à empresa que foi analisada no presente trabalho. Abaixo
seguem as best practices mais importantes a serem adotadas bem como ações necessárias no
intuito de aprimorar a maturidade em gerenciamento de projetos em comunicação da empresa
em questão:
Best Practice 1160 - Padronização do processo de Comunicação do projeto.
Ação: Implementação de um formulário de informações de progresso das atividades.
Best Practice 2110 - A organização demonstra o retorno de projetos executados.
Ação: Implementação de um relatório de desempenho contemplando a Análise de
Valor Agregado dos projetos em andamento.
Best Practice 3030 - A empresa coleta e compartilha lições aprendidas dos projetos,
programas e portfolio.
Ação: Implementação de um relatório de Desempenho e EVA
Best Practice 3000 - Problemas na área do processo de encerramento de projeto são
estimadas, recomendações de melhoria do processo são coletadas, e melhorias do processo
são implementadas.
Ação: análises dos hitóricos dos relatórios de desempenho, EVA e não conformidade
assim que estes passarem a existir.
Reforçando a importância de um crescente aprimoramento das comunicações nos
projetos ressalta-se que uma equipe de projetos com grandes talentos altamente motivados
não é suficiente se ela não esiver bem informada. Se seus integrantes não se comunicarem da
195
forma correta torna-se iviável potencializar a força humana da empresa, cabendo assim
lembrar mais algumas orientações a respeito do processo de comunicação.
Inicialmente, vale destacar que a piadinha reproduzida na figura abaixo é válida em
muitas situações.
fonte: domínio público, recebido por email em 04 de março de 2003.
E enquanto houverem pessoas se comunicando sem a observação de pontos simples,
mencionados a seguir, infelizmente a figura continuará ocorrendo.
A comunicação interna é otimizada na medida em que cada membro da empresa
estiver também envolvido o suficiente para “caçar” as informações das quais necessita, sem
esperar que elas “venham de cima”. É fundamental que uma cultura nesse sentido seja
fortemente implantada em todos os níveis da empresa, principalmente nestes atuais tempos de
transição.
A comunicação efetiva só se estabelece em clima de verdade e autenticidade. Caso
contrário, só haverá jogos de aparência, desperdício de tempo e, principalmente, uma
“anticomunicação” no que é essencial e necessário.
Não basta assegurar que a comunicação “ocorra”. É preciso fazer com que o
conteúdo seja efetivamente aprendido, para que as pessoas estejam em condições de usar (o
que é informado).
196
A seguir reproduzimos outra figura, ilustrando como um planejamento eficiente do
processo de comunicação percorre etapas, mas garante que o produto obtido seja eficaz e
suficiente para as necessidades de um projeto.
Fonte:http://ambienteaprendiz.bvs.br/processos/GA_-_Unidade_de_Comunicacao
_Integrada_-_UCI/Processo_de_Projeto_de_Comunicacao/UCI_Ciclo_Realizacao_Projetos
_2006 01.jpg, acesso em 20 de fevereiro de 2009.
Qualidade da comunicação deve pressupor a personalização do processo em função
das naturais diferenças de diversos quadros de referência, nível de experiência, amplitude de
interesses, motivação, etc. Comunicações feitas para a média do público acabam gerando mais
197
problemas do que benefícios, sem falar do fato de a pasteurização tornar as mensagens
inócuas ou sem impacto.
Bibliografia
SCHNEIDER, Guilherme. O gerente de projetos também cuida da comunicação.
Disponível em http://webinsider.uol.com.br/index.php/2008/11/05/o-gerente-de-projetos-
tambem-cuida-da-comunicacao/. Acesso em 15 de janeiro de 2009.
198
9.5 WALTER RIBEIRO DE OLIVEIRA JR
A ADAPTAÇÃO DA GERÊNCIA DE PROJETOS A CADA PROJETO
É um conceito básico, aprendido logo ao início de qualquer curso de
gerenciamento de projetos que utilize o Project Management Body of Knowledge (PMBoK),
que o PMBoK não é uma metodologia de gerência de projetos. É sim uma coletânea bastante
vasta e aprofundada de experiências de gerenciamento de projetos colhidas ao redor do
mundo, com vários especialistas, e que depois é transformada em um conjunto de melhores
práticas a serem seguidas.
Deste seu caráter de agregação de experiências é que surge sua primeira
característica marcante: um gerente de projetos que esteja frente ao seu primeiro projeto até
poderá saber como conduzir este projetos a partir de experiências anteriores. Não terá sucesso,
entretanto, em adquirir o PMBoK e tentar implantar todas as suass práticas já de início.
Muitos dos conceitos utilizados no PMBoK esperam que haja um conhecimento mínimo, uma
experiência mínima, sobre a gerência de projetos. E isto não se dá a uma dificuldade criada
propositadamente pelo PMI (Project Management Institute). Este conhecimento é necessário
para que a pessoa, ao utilizar as práticas do PMBoK, tenha discernimento em adaptar a sua
realidade ao projeto que está conduzindo. Caso contrário, haverá um sufocamento com a
quantidade de processos existentes, que poderão não ser necessários ao projeto em particular.
A utilização do PMBoK, em sua completude, em projetos de pequeno porte,
poderá resultar em um maior gasto de tempo e recursos com práticas que não terão resultados
concretos ou apreciáveis. Estes mesmos ensinamentos, entretanto, podem ser utilizados
integralmente quando um projeto possui um porte maior, ou mesmo pode-se chegar ao ponto
onde o Gerente de Projeto sinta necessidade de ir além do que o PMBoK apresenta, e assim
acabe por utilizar partes de outros ensinamentos sobre gerenciamento de projetos.
199
1. A integração do PMBoK com metodologias rápidas de de desenvolvimento
Por exemplo, uma das aparentes incompatibilidades que podem existir, para um
Gerente de Projetos, é como desenvolver projetos utilizando metodologias ágeis (por
exemplo, o SCRUM), e ao mesmo tempo tentar aplicar o PMBoK.
A integração entre estes conhecimentos é perfeitamente possível, pois enquanto o
SCRUM poderá ser utilizado para a obtenção das pequenas entregas do projeto, o PMBoK é
utilizado para o gerenciamento de alto nível das atividades. Ou seja, enquanto o SCRUM seria
utilizado para os pacotes de trabalho, o PMBoK seria responsável por cuidar da gerência de
custos, de aquisições, de comunicações, dos riscos (talvez em um nível macro). E assim
poder-se-ia unir o melhor de cada mundo: ao mesmo tempo que se tenha um gerenciamento
ágil e pouco burocrático dos entregáveis, haveria um gerenciamento robusto e bastante
estruturado do projeto como um todo.
E o mesmo se dá à integração com qualquer outra metodologia que vise uma
maior agilidade, ou que seja desenvolvida tendo-se como objetivo apenas um determinado
conjunto de atividades (por exemplo, específico para o desenvolvimento de softwares).
Conforme haja maior conhecimento pelo gerente de projeto, melhores resultados
serão obtidos pela tentativa de integração entre processos de fontes diferentes.
2. A adequação do PMBoK aos projetos de pequeno porte
O mesmo raciocínio aplica-se à utilização do PMBoK em projetos de pequeno
porte, como é o caso da empresa que foi objeto deste estudo. Ao tentar utilizar todas as
recomendações e todos os processos do PMBoK, certamente o Gerente de Projeto (ou sua
equipe) terão que dedicar uma parte de seu tempo, garantindo que hava coerência entre todos
os processos.
200
Se houver, entretanto, discernimento do Gerente de Projeto (o que é conquistado,
em geral, com a experiência e com o estudo), poderá ser feita uma seleção das recomendações
que façam sentido para cada projeto. Desta forma o projeto será beneficiado pela utilização de
práticas já bastante testadas e referendadas, o que aumentará a sua chance de sucesso dentro
das restrições de tempo, custo e escopo.
3. Um "PMBoK" para cada projeto
A atividade de gerenciar um projeto é verificada cotidianamente dentro das mais
diversas áreas, por vezes mesmo sem que o executor tenha consciência que está planejando ou
executando um projeto.
Já a arte de gerenciar projetos é mais restrita. É adquirida por poucos, após muita
dedicação e muita reflexão sobre as experiências havidas. E o que diferencia a atividade da
arte não é simplesmente a obtenção do resultado de sucesso, pois mesmo projetos mal
planejados e mal executados poderão atingir os seus objetivos. A diferença surge quando o
gerente de projeto dispõe de conhecimento e de ferramentas (por exemplo, o PMBoK), e sabe
quando e como utilizar a ferramenta. Assim, para cada projeto, para cada objetivo, para cada
equipe, um conjunto diferente de processos vai sendo utilizada e vai sendo aperfeiçoada. Em
pouco tempo se tem a otimização entre a quantidade de esforço que é utilizada em um
determinado processo (por exemplo, quanto esforço é dedicado às comunicações feitas
durante o projeto) e os resultados que são obtidos.
E mesmo projetos bastante parecidos, inclusive envolvendo as mesmas pessoas,
poderão exigir um conjunto bastante diverso de práticas. Haverão casos onde durante a
execução do projeto é que se perceberá que um determinado processo está sendo necessário, e
então mesmo que com atraso este processo será iniciado. O que fará a diferença será o senso
de oportunidade da utilização da ferramenta no momento adequado, ou mesmo no momento
que ainda é possível e vantajoso o seu uso.
201
4. O PMBoK como troca de experiências
Outra característica interessante do PMBoK, dita ao início mas que será realçada
apenas agora, é que o PMBoK surgiu justamente a partir da troca de experiências entre
gerentes de projeto. Todo o esforço para compilar este conhecimento em uma obra (sujeita a
atualizações constantes, mesmo que espaçadas) decorre unicamente da contínua troca de
experiências entre os gerentes de projeto.
Assim não existem dogmas que sejam insuperáveis, pois o PMI não trabalha com
dogmas. Não há um trabalho único, construído a partir do zero, por uma pequena equipe de
pessoas.
Maior prova é a nova versão do PMBoK, lançada recentemente, que apresenta
mudanças em relação ao PMBoK 3ª edição, de 2004. Por exemplo, houve uma simplificação
no processo de aquisições, com os itens "solicitar respostas de fornecedores" e "selecionar
fornecedores" sendo substituídos apenas pelo item "conduzir aquisições". Ou, em outro
exemplo, a eliminação do processo de "elaboração preliminar de escopo".
Desta forma verifica-se que o PMBoK, que já era bastante completo em sua 3ª
edição, pode ser otimizado e aperfeiçoado com a verifcação de como era feita a sua utilização.
E certamente sofrerá novas revisões no futuro, conforme haja o amadurecimento das práticas
e processos que são recomendados agora.
5. Conclusão
O PMBoK possui um conhecimento enorme compilado em seus processos. Este
conhecimento decorre da troca de experiências entre diversos gerentes de projeto, e a sua
compilação em uma obra. Desta fonte bastante diversificada é natural que existam processos
202
que pareçam não serem úteis em todos os projetos, seja por sua área de atuação, seja por seu
porte.
Cabe ao gerente de projeto saber utilizar todo este conhecimento em cada projeto
que for fazer parte, dando maior ênfase aos processos cujos resultados sejam compensadores,
quando comparados ao esforço necessário ao seu gerenciamento.
Isto também é válido para as integrações que possam se fazer necessárias entre as
recomendações do PMBoK e os conhecimentos oriundos de outras fontes, seja de outras
técnicas de gerenciamento de projetos, seja de metodologias específicas.
Ao saber fazer estas ponderações o gerente de projeto estará mais habilitado a
utilizar os conhecimentos que cada projeto seu exigir, evitando que haja um desperdício
grande de energia em processos que não sejam fundamentais para um determinado projeto.
Referência bibliográfica
BARCAUI, A.. Gerência de Projetos Arte ou Liderança?. Revista Mundo PM, n.09, ano2, jun/jul.2006.
DANTAS, F. Comparativo PMBOK 2004 x PMBOK 2008. Disponível em http://certificacaopmp.wordpress.com/2008/09/01/comparativo-pmbok-2004-x-pmbok-2008/. Acesso em 13 de janeiro de 2009.
PMI. Project Management Body of Knowledge (PMBoK). Project Management Institute. Newton Square, PA. EUA, 2004.
PMI. Project Management Body of Knowledge (PMBoK). Project Management Institute. Newton Square, PA. EUA, 2008.
SOBH, T. e FITSILIS, P. Comparing PMBOK and Agile Project Management software development processes. In: Advances in Computer and Information Sciences and Engineering. Amsterdã, 2008: Springer Netherlands. pags 378-383.
WUTTKE, T.. PMBOK® Guide version 2008. Disponível em http://www.threon.com/en/news/details/article/pmbokR-guide-version-2008/. Acesso em 05 de março de 2009.