A ANÁLISE DA MATURIDADE E RECOMENDAÇÕES DE MELHORES ... · elaboração dos trabalhos para...

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


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


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


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


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


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


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


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%


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.

50


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.


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


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

http://www.efagundes.com/artigos/CMM.htm

http://www.maturityresearch.com/

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

88

8.2 APÊNDICE II – LISTA DE BOAS PRÁTICAS

130

8.3 APÊNDICE III – LISTA DE CORRESPONDÊNCIA ENTRE PERGUNTAS E BOAS

PRÁTICAS

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


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


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


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


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


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,


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,


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


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,


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

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


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>

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>


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

159

8.5.5 Recursos Humanos


160

8.5.6 Comunicação

Relatório de Não-conformidades

161

8.5.7 Riscos

Levantamento de riscos

<Nome-Empresa>



Data: Responsável

Id Risco Área Probabilidade Impacto

Financeiro

Impacto em

Dias

162

Mitigação de Riscos

<Nome-Empresa>



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


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>


<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


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


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.

http://www.scribd.com/doc/4672356/Gerencia-Projetos-Software-CMM-PMBOK

http://www.scribd.com/doc/4672356/Gerencia-Projetos-Software-CMM-PMBOK

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


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


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.



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.

A ANÁLISE DA MATURIDADE E RECOMENDAÇÕES DE MELHORES ... · elaboração dos trabalhos para...

Documents

Transcript of A ANÁLISE DA MATURIDADE E RECOMENDAÇÕES DE MELHORES ... · elaboração dos trabalhos para...