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.

Tamanho: px
Começar a partir da página:

Download "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."

Transcrição

1 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

2 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

3

4 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 JOÃO OSWALDO MAZUR Sócio-Diretor Wasys Tecnology

5 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 DANIELE MARTINS FERNANDO REZENDE CELESTINO JOÃO OSWALDO MAZUR MARCELO

6 STIVAL WALTER RIBEIRO DE OLIVEIRA JR

7 Dedicamos este trabalho a todos os que nos acompanharam e apoiaram durante este MBA: familiares, amigos, professores e colegas.

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

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

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

11 SUMÁRIO 1 INTRODUÇÃO CONSIDERAÇÕES INICIAIS FUNDAMENTAÇÃO TEÓRICA O QUE É MATURIDADE EM GERENCIAMENTO DE PROJETOS MODELOS DE MATURIDADE EM GERENCIAMENTO DE PROJETOS Modelo Prado - MMGP Modelo CMMI O OPM Outros modelos METODOLOGIA CIENTÍFICA CONSIDERAÇÕES INICIAIS A EMPRESA O CONTEXTO O OBJETIVO O CENÁRIO ALVO A ESCOLHA DO MODELO DE MATURIDADE A ADEQUAÇÃO DO MODELO OPM O MODELO SUGERIDO ANÁLISE DOS RESULTADOS CONSIDERAÇÕES INICIAIS RESULTADOS DISCUSSÃO DOS RESULTADOS Integração Escopo Tempo Custo Qualidade Recursos Humanos Comunicação Riscos Aquisições CONCLUSÕES POSSÍVEIS DESDOBRAMENTOS...65

12 7 REFERÊNCIAS BIBLIOGRÁFICAS APÊNDICES APÊNDICE I LISTA DE PERGUNTAS APÊNDICE II LISTA DE BOAS PRÁTICAS APÊNDICE III LISTA DE CORRESPONDÊNCIA ENTRE PERGUNTAS E BOAS PRÁTICAS APÊNDICE IV LISTA DE PERGUNTAS E BOAS PRÁTICAS APÊNDICE V: MODELOS DE DOCUMENTOS Integração Escopo Custos Qualidade Recursos Humanos Comunicação Riscos Aquisições APÊNDICE VI: QUESTIONÁRIO RESPONDIDO PELA EMPRESA APÊNDICES POR AUTOR INDIVIDUAL DANIELE MARTINS FERNANDO REZENDE CELESTINO JOÃO OSWALDO MAZUR MARCELO STIVAL WALTER RIBEIRO DE OLIVEIRA JR...198

13 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

14 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 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 , 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 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 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 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 Disponível em 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 Disponível em 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 19 Figura 2: Nível de Maturidade por Tipo de Organização (Fonte: PRADO, Darci, ARCHIBALD, Russell. Pesquisa Sobre Maturidade em Gerenciamento de Projetos, Relatório Anual Disponível em Acesso em 26/11/2008) Ainda é possível classificar o grau de maturidade de acordo com as categorias de projetos do modelo de Archibald. A figura 3 mostra esta classificação. Figura 3: Grau de Maturidade por Categoria de Projeto. (Fonte: PRADO, Darci, ARCHIBALD, Russell. Pesquisa Sobre Maturidade em Gerenciamento de Projetos, Relatório Anual Disponível em Acesso em 26/11/2008) Uma última e importante classificação é pelo ramo de atividade da empresa. Esta classificação está na figura 4.

20 20 Figura 4: Grau de Maturidade por Área de Atuação (Fonte: PRADO, Darci, ARCHIBALD, Russell. Pesquisa Sobre Maturidade em Gerenciamento de Projetos, Relatório Anual Disponível em Acesso em 26/11/2008) A partir destes dados é possível concluir que as organizações ainda possuem um longo caminho rumo a uma maior maturidade em gerenciamento de projetos. Os resultados desta pesquisa mostram que 65,5% das organizações participantes estão no nível 1 e 2, ou seja, ainda não implantaram padrões, métodos, estruturas ou sistemas de gerenciamento de projetos que possa trazer resultados aos seus negócios. E somente 9% das organizações estão em níveis 4 e 5, onde o domínio do processo de gerenciamento de projetos é alcançado. 2.2 MODELOS DE MATURIDADE EM GERENCIAMENTO DE PROJETOS Os modelos de maturidade, além de mensurar o estágio da organização na habilidade de gerenciar seus projetos, em geral permitem também classificar as empresas em categorias de maturidade, possibilitando o benchmark entre empresas. E nestes modelos as empresas podem formular seu planejamento estratégico de melhoria, pois a partir do conhecimento do estágio atual é possível estabelecer um caminho para atingir outros níveis 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 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 Modelo CMMI Figura 5: Níveis de Maturidade no Modelo Prado-MMGP (Fonte: PRADO, Darci, ARCHIBALD, Russell. Pesquisa Sobre Maturidade em Gerenciamento de Projetos, Relatório Anual Disponível em Acesso em 26/11/2008) 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 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 Acesso em 28/11/2008.) 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 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 PMBoK 1, 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 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 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 26 3 METODOLOGIA CIENTÍFICA 3.1 CONSIDERAÇÕES INICIAIS A empresa objeto de estudo deste trabalho deseja implementar um programa de melhorias no processo de gerência de projetos, porém sem burocratizar em excesso ou a ponto de diminuir sua eficiência. A equipe que desenvolveu este trabalho buscou o estudo e seleção do melhor modelo de maturidade a ser aplicado e utilizado pela empresa. Após a escolha do modelo de maturidade o esforço resumiu-se na otimização do questionário de avaliação para determinar qual o grau de maturidade da empresa, pois tão importante quanto chegar a algum lugar é necessário saber onde se está. Em seguida foram feitas considerações sobre processos que a empresa poderia adotar, conforme as respostas que a empresa forneceu no questionário, para que pudesse aumentar o seu grau de maturidade em gerenciamento de projetos. 3.2 A EMPRESA Fundada em 1995 a Wasys é uma empresa integradora de soluções de TI. Desenvolve soluções personalizadas usando as boas práticas de desenvolvimento do mercado, baseada em tecnologias e metodologias amplamente aceitas. Além disso, a Wasys tem diversas parcerias estratégicas que visam a distribuição de produtos de software e hardware necessários à infra-estrutura da solução. Dentre as parcerias de destaque podem-se citar a IBM, Microsoft e Claro. Nos treze anos de existência a empresa passou por diversas evoluções e melhorias na gerência de seus projetos, principalmente buscando a qualificação de seus gerentes de projeto. 3.3 O CONTEXTO A empresa é basicamente voltada para desenvolvimento de projetos de desenvolvimento de software ou prestação de serviços de informática. Seus contratos com clientes possuem as principais características de projetos: são temporários, possuindo um início e um fim definidos; são planejados, executados e controlados; entregam produtos, serviços ou resultados exclusivos. A empresa em análise encontra os desafios e problemas encontrados em outras empresas na implantação e desenvolvimento de projetos.

27 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 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 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 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, interrelacionamento 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 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 31 Tabela 2: Relação de pesos versus utilização Peso Frequência de verificação 0 Nunca 1 Raramente 2 Algumas vezes 3 Metade das vezes 4 Várias vezes 5 Sempre Fonte: os próprios autores Todas as perguntas foram relacionadas a áreas de conhecimento do PMBoK, sendo que algumas das perguntas se referem à cultura organizacional da empresa ou a mais de uma área de conhecimento. Para estas os autores indicaram um novo código, conforme demonstrado na tabela 3. Tabela 3: Relação das Áreas de Conhecimento Área de Conhecimento Descrição 4 Integração 5 Escopo 6 Tempo 7 Custo 8 Qualidade 9 RH 10 Comunicação 11 Riscos 12 Aquisições 99 Cultura da empresa Várias Fonte: os próprios autores

32 32 Também houve um relacionamento entre as perguntas e a seu estágio de melhoria (conforme explicado no item 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 Cultura da empresa 5 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 33 4 ANÁLISE DOS RESULTADOS 4.1 CONSIDERAÇÕES INICIAIS O formulário de questionário foi respondido em conjunto pelos três gerentes de projetos da empresa, o que possibilitou uma maior veracidade e reflexo da visão de cada um sobre seus projetos e sobre todos os projetos da empresa. No apêndice VI reproduzimos o questionário respondido. 4.2 RESULTADOS Os resultados obtidos demostraram que a empresa possui uma baixa maturidade em gerenciamento de projetos, como já era esperado pelas informações fornecidas antes da avaliação. Os resultados obtidos por área de conhecimento estão na tabela 5, onde é possível verificar que existe uma relativa preocupação da empresa em algumas áreas de conhecimento. A atenção principal da empresa ocorre nas áreas em que há um peso maior em projetos, como escopo e tempo, porém faltam esforços em outras áreas importantes, como custos, comunicação e riscos, que poderiam ser um diferencial competitivo no mercado. Tabela 5: Resultados por Área de Conhecimento Área de conhecimento Nota Integração 21,67% Escopo 23,33% Tempo 29,09% Custo 7,69% Qualidade 12,50% RH 0,00% Comunicação 0,00% Riscos 0,00% Aquisições 11,43% Estrutura da Empresa 27,73%

34 34 Média Geral 13,34% Fonte: os próprios autores Outra forma de interpretação dos resultados é separando por estágios de maturidade, conforme demonstrado na Tabela 6. Verifica-se que a preocupação da empresa com seu grau de maturidade é coerente, pois a formalização de processos é quase inexistente. Tabela 6: Resultados dos Estágios de Maturidade Resultado por domínio Padronizar 0,83% Medir 31,67% Controlar 17,06% Aprimorar 12,50% Estrutura da Empresa 39,00% Fonte: os autores Os autores do presente trabalho destacam que os resultados mostrados nestas duas tabelas comprovam que houve bastante coerência no trabalho feito. Os resultados por área de conhecimento mostram que houve correspondência entre as informações que eram conhecidas sobre a empresa e as respostas dadas ao questionário. Já as respostas dos estágios de maturidade comprovaram que a empresa aplica apenas seus conhecimentos empíricos, mas não possui formalidades em seus projetos, também conforme havia sido informado no perfil da empresa. Apesar do relativo sucesso nos projetos desenvolvidos por ela, vale destacar que ela poderá se beneficiar com a adoção do modelo de maturidade aqui proposto, pois permitirá avaliar e elaborar um plano estratégico para melhoria dos processos de gerenciamento de projetos. Um processo de gerenciamento de projetos é uma garantia a mais da continuidade de sucesso dos projetos, assim como um diferencial competitivo frente aos seus concorrentes.

35 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 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 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 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 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 (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 (Riscos, pag. 58), a empresa não possui qualquer controle de riscos, sendo uma grande oportunidade

39 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 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 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 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 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 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 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 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 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 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 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 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 renegociação com o cliente.

48 48 Assim serão obtidos os seguintes documentos formais: orçamento e linha base de custos. Uma segunda sugestão é que a empresa adote um processo de controle de custos do projeto. Os seguintes itens são necessários como entrada deste processo: orçamento (linha base de custos), cronograma (linha base de tempo), WBS e Dicionário (linha base de escopo) e informações coletadas sobre andamento das atividades. Os passos a serem seguidos pela empresa, que deverão ser repetidos periodicamente, em intervalos definidos conforme o tamanho e a criticidade do projeto, são os seguintes: 1. Gerente de Projeto coleta informações sobre o andamento das atividades já iniciadas e não concluídas. Para isso, gera uma tabela conforme documentos sugeridos no apêndice V (item 8.5.3, Error: Reference source not found, pag.154 e Error: Reference source not found, pag. 155), a partir do sistema de controle de atividades, e preenche os estimados para completar o projeto (estimate to complete the project - ETC s) com base em informação obtida com os recursos responsáveis por cada atividade; 2. O Gerente de Projeto insere as informações coletadas no sistema de controle atividades (por exemplo, no Microsoft Project); 3. O Gerente de Projeto utiliza o sistema de controle de atividades para gerar os valores dos indicadores descritos abaixo, do earned value analysis (EVA), e transcreve os mesmos em relatório de progresso conforme os indicadores EVA mostrados na Error: Reference source not found; 4. O Gerente de Projeto analisa os indicadores para identificar possível necessidade de ações corretivas ou change requests; 5. O Gerente de Projeto dá início a ações corretivas ou change requests, quando aplicável. Um Change Request, quando aprovado, deverá gerar alteração na linha base de custos e, provavelmente, nas linhas base de tempo e escopo. Tabela 7: Indicadores EVA.

49 49

50 50 Fonte: os próprios autores Deste processo serão gerados os seguintes itens: relatório de progresso de custos, change requests, ações corretivas e linha base de custos atualizada. Por fim, sugere-se que a empresa adote as seguintes métricas para os processos de custos:

51 Percentual de esforço gasto nestas fases com relação ao esforço total do projeto: a partir da estimativa inicial de esforço do projeto, utilizada para fechar o contrato com o cliente (o que é feito antes da etapa de planejamento detalhado), pode-se determinar qual o porcentual de tempo ou esforço/custo está sendo gasto com os referidos processos, comparado com o esforço/tempo total do projeto. Isso possibilitará a criação de uma base histórica que possibilitará estimativas mais realistas para estas atividades em projetos futuros. Também possibilitará saber se um projeto está gastando mais tempo que o normal com algum destes processos, possivelmente trazendo a tona um problema de projeto que sem esta medição ficaria oculto por mais tempo, podendo gerar mais prejuízos; Indicadores do EVA: a medição periódica destes indicadores também possibilitará a geração de histórico, e a identificação precoce de problemas, comparando-se o mesmo com o histórico existente. Além disso, poderá apontar prováveis problemas com o processo de estimativa de tempo (e consequentemente de custos) para as atividades, ou na própria execução das mesmas. Recomenda-se que a empresa verifique estes indicadores quinzenalmente. No apendice V são colocados modelos de documentos para as sugestões apresentadas para o controle de escopo 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, : "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 51 2 MARSHALL Jr, I.; et al. Gestão da Qualidade. Rio de Janeiro: Editora FGV, 2007 p

52 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 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 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, : a previsibilidade acontece pela obediência aos padrões, pois, quando a melhoria é bemsucedida, adota-se o método planejado, padronizando-o; caso contrário, volta-se ao padrão anterior e recomeça-se a girar o PDCA. No apendice V são colocados modelos de documentos para as sugestões apresentadas para o controle de qualidade 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

54 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 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 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 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 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, 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: , edital, telefone, reuniões; 5. Frequência de comunicações: 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" 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. 58

59 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) 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 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 (pag. 35) referente ao gerenciamento de integração do projeto.

61 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 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 (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 (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 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 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 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 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 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, 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, PMI. Project Management Body of Knowledge (PMBoK). Project Management Institute. Newton Square, PA. EUA, PRADO, D., ARCHIBALD, R. Pesquisa Sobre Maturidade em Gerenciamento de Projetos, Relatório Anaual Disponível em Acesso em 26/11/2008. Gerenciamento de Portifólios, Programas e Projetos nas Organizações. São Paulo, INDG, RAJ,P. P. et al. Gerenciamento de pessoas em projetos, Editora FGV, 2008 SALLES JR, C. A. C. et al. Gerenciamento de riscos em projetos, Editora FGV, 2007 SOTILLE, M. A. et al. Gerenciamento do escopo em projetos - 2ª edição, Editora FGV, 2008 VALLE, A. B. do et al. Fundamentos do gerenciamento de projetos, Editora FGV, 2007 VARGAS, R. V. Gerenciamento de Projetos Estabelecendo Diferenciais. Brasport, 2005

67 XAVIER, C. M. da S.. Gerenciamento de Projetos: como definir e controlar o escopo do projeto. Saraiva, 2008 et al. Gerenciamento de aquisições em projetos, Editora FGV, Methodologia de Gerenciamento de Projetos: Methodware (3ª Edição). Brasport,

68 68 8 APÊNDICES 8.1 APÊNDICE I LISTA DE PERGUNTAS

69 69

70 70

71 71

72 72

73 73

74 74

75 75

76 76

77 77

78 78

79 79

80 80

81 81

82 82

83 83

84 84

85 85

86 86

87 87

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

89 89

90 90

91 91

92 92

93 93

94 94

95 95

96 96

97 97

98 98

99 99

100 100

101 101

102 102

103 103

104 104

105 105

106 106

107 107

108 108

109 109

110 110

111 111

112 112

113 113

114 114

115 115

116 116

117 117

118 118

119 119

120 120

121 121

122 122

123 123

124 124

125 125

126 126

127 127

128 128

129 129

130 APÊNDICE III LISTA DE CORRESPONDÊNCIA ENTRE PERGUNTAS E BOAS PRÁTICAS

131 131

132 132

133 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 134 de iniciação?número da Best PracticeBest Practice2240Controles de processo de Iniciação são estabelecidos e executados para controlar a estabilidade do processo.2250controles de processo de Desenvolvimento do Plano de Projeto são estabelecidos e executados para controlar a estabilidade do processo.1710estabelecer, compilar e analisar métricas do processo de desenvolvimento do plano de projeto.1920estabelecer, compilar e analisar métricas do processo de planejamento de execução do plano.1700estabelecer, compilar e analisar métricas do processo de iniciação.pergunta nº15perguntasua organização estabelece e analisa métricas para serem utilizadas no acompanhamento da fase de planejamento de escopo?número da Best PracticeBest Practice2270Controles de processo de Definição de Escopo são estabelecidos e executados para controlar a estabilidade do processo.2010estabelecer, compilar e analisar métricas do processo de verificação de escopo.2260controles de processo de Planejamento de Escopo são estabelecidos e executados para controlar a estabilidade do processo.1720estabelecer, compilar e analisar métricas do planejamento de escopo.1730estabelecer, compilar e analisar métricas do processo de definição de escopo.pergunta nº16perguntasua organização estabelece e analisa métricas para serem utilizadas no acompanhamento da fase de planejamento de tempo?número da Best PracticeBest Practice2300Controles de processo de Estimativa de Duração de Atividades são estabelecidos e executados para controlar a estabilidade do processo.2310controles de processo de Desenvolvimento de Cronograma são estabelecidos e executados para controlar a estabilidade do processo.2280controles de processo de Definição de Atividades são estabelecidos e executados para controlar a estabilidade do processo.2290controles de processo de Sequenciamento de Atividades são estabelecidos e executados para controlar a estabilidade do processo.1770estabelecer, compilar e analisar métricas do processo de desenvolvimento de cronograma.2030estabelecer, compilar e analisar métricas do processo de controle de cronograma.1750estabelecer, compilar e analisar métricas do processo de sequenciamento de atividades.1760estabelecer, compilar e analisar métricas do processo de estimativa de duração de atividades.1740estabelecer, compilar e analisar métricas do processo de definição de atividades.pergunta nº17perguntasua organização estabelece e analisa métricas para serem utilizadas no acompanhamento da fase de planejamento de custo? Número da Best PracticeBest Practice2330Controles de processo de Estimativa de Custos são estabelecidos e executados para controlar a estabilidade do processo.2340controles de processo de Orçamentação são estabelecidos e executados para controlar a estabilidade do

135 135 processo.2040estabelecer, compilar e analisar métricas do processo de controle de custos.2060estabelecer, compilar e analisar métricas do processo de monitoramento e controle de riscos.1790estabelecer, compilar e analisar métricas do processo de estimativa de custos.1800estabelecer, compilar e analisar métricas do processo de orçamentação.pergunta nº18perguntasua organização estabelece e analisa métricas para serem utilizadas no acompanhamento da fase de planejamento de qualidade?número da Best PracticeBest Practice2050Estabelecer, compilar e analisar métricas do processo de controle de qualidade.2360controles de processo de Planejamento da Gerência de Riscos são estabelecidos e executados para controlar a estabilidade do processo.1820estabelecer, compilar e analisar métricas do processo da qualidade..1930estabelecer, compilar e analisar métricas do processo de garantia de qualidade.pergunta nº19perguntasua organização estabelece e analisa métricas para serem utilizadas no acompanhamento da fase de planejamento das aquisições?número da Best PracticeBest Practice1900Estabelecer, compilar e analisar métricas do processo de planejamento de aquisições.1910estabelecer, compilar e analisar métricas do processo de planejamento de solicitação.pergunta nº20perguntasua organização estabelece e analisa métricas para serem utilizadas no acompanhamento da fase de planejamento de Recursos Humanos?Número da Best PracticeBest Practice1780Estabelecer, compilar e analisar métricas do processo de planejamento de recursos.2320controles de processo de Planejamento de Recursos são estabelecidos e executados para controlar a estabilidade do processo.pergunta nº21perguntasua organização estabelece e analisa métricas para serem utilizadas no acompanhamento da fase de planejamento de Riscos?Número da Best PracticeBest Practice2400Controles de processo de Planejamento da Gerência de Riscos são estabelecidos e executados para controlar a estabilidade do processo.1890estabelecer, compilar e analisar métricas do processo de planejamento de resposta aos riscos.2350controles de processo de Planejamento da Gerência de Riscos são estabelecidos e executados para controlar a estabilidade do processo.1870estabelecer, compilar e analisar métricas do processo de análise qualitativa de riscos.1880estabelecer, compilar e analisar métricas do processo de análise quantitativa de riscos.1810estabelecer, compilar e analisar métricas do processo de planejamento da gerência de riscos.1860estabelecer, compilar e analisar métricas do processo de identificação de riscos.pergunta nº22perguntasua organização estabelece e analisa métricas para serem utilizadas no acompanhamento da fase de planejamento de Controle de

136 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 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 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 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 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 141 de controle de mudanças de custos do projeto é aplicado?número da Best PracticeBest Practice2580Processos de controle de mudanças de custo do projeto são estabelecidos e executados para controlar a estabilidade do processopergunta nº58perguntaé feita uma estimativa de problemas que poderão surgir sobre a estimativa de custos do projeto?número da Best PracticeBest Practice2720Problemas na área do processo de estimativa de custos são estimadas, recomendações de melhoria do processo são coletadas, e melhorias do processo são implementadas.pergunta nº59perguntaé feita a coleta de informações sobre problemas surgidos de custos mal definidos?número da Best PracticeBest Practice2720Problemas na área do processo de estimativa de custos são estimadas, recomendações de melhoria do processo são coletadas, e melhorias do processo são implementadas.pergunta nº60perguntasão implementadas melhorias na estimativa de custos dos projetos baseando-se em informações coletadas em projetos anteriores?número da Best PracticeBest Practice2720Problemas na área do processo de estimativa de custos são estimadas, recomendações de melhoria do processo são coletadas, e melhorias do processo são implementadas.pergunta nº61perguntaé feita a coleta de informações sobre problemas surgidos na elaboração de relatórios de desempenho?número da Best PracticeBest Practice2920Problemas na área do processo de relatório de desempenho são estimadas, recomendações de melhoria do processo são coletadas, e melhorias do processo são implementadas.pergunta nº62perguntasão implementadas melhorias na elaboração de relatório de desempenho baseando-se em informações coletadas em projetos anteriores? Número da Best PracticeBest Practice2920Problemas na área do processo de relatório de desempenho são estimadas, recomendações de melhoria do processo são coletadas, e melhorias do processo são implementadas.pergunta nº63perguntaé feita a coleta de informações sobre a ocorrência de riscos e as respostas dadas durante a execução do projeto? Número da Best PracticeBest Practice2400Controles de processo de Planejamento da Gerência de Riscos são estabelecidos e executados para controlar a estabilidade do processo.2430processo de controle de planejamento de respostas a riscos de projeto são estabelecidos e executados para controlar a estabilidade do processopergunta nº64perguntasão implementadas melhorias no levantamento de riscos e no planejamento de respostas a riscos baseando-se em informações coletadas em projetos anteriores?número da Best PracticeBest Practice2790Problemas na área do processo de identificação de riscos são estimadas, recomendações de melhoria do processo são coletadas, e melhorias do processo

142 142 são implementadas.pergunta nº65perguntahá um procedimento de encerramento de projetos? Número da Best PracticeBest Practice2610Processos de controle de encerramento de contrato do projeto são estabelecidos e executados para controlar a estabilidade do processopergunta nº66perguntao procedimento de encerramento de projetos é aplicado?número da Best PracticeBest Practice2610Processos de controle de encerramento de contrato do projeto são estabelecidos e executados para controlar a estabilidade do processopergunta nº67perguntaé feita a coleta de informações sobre problemas surgidos no processo de encerramento do projeto?número da Best PracticeBest Practice3000Problemas na área do processo de encerramento de projeto são estimadas, recomendações de melhoria do processo são coletadas, e melhorias do processo são implementadas.pergunta nº68perguntasão implementadas melhorias no processo de encerramento do projeto baseando-se em informações coletadas em projetos anteriores?número da Best PracticeBest Practice3000Problemas na área do processo de encerramento de projeto são estimadas, recomendações de melhoria do processo são coletadas, e melhorias do processo são implementadas.pergunta nº69perguntahá a coleta de informações de lições aprendidas no projeto?número da Best PracticeBest Practice3040A equipe de projeto captura, acessa, recupera e aplica as lições aprendidas3030a empresa coleta e compartilha lições aprendidas dos projetos, programas e portfoliopergunta nº70perguntaas informações de lições aprendidas são compartilhadas pelas equipes de projetos?número da Best PracticeBest Practice3030A empresa coleta e compartilha lições aprendidas dos projetos, programas e portfoliopergunta nº71perguntaas informações de lições aprendidas são utilizadas em novos projetos?número da Best PracticeBest Practice3040A equipe de projeto captura, acessa, recupera e aplica as lições aprendidaspergunta nº72perguntaé realizado benchmarking para comparar o desempenho de projetos?número da Best PracticeBest Practice3050A empresa utiliza a técnica de benchmarking para melhorar continuamente o desempenho de projetospergunta nº73perguntahá apoio da empresa para as equipes de projeto através de suporte técnico ou de um bom ambiente de trabalho?número da Best PracticeBest Practice3090A empresa cria um ambiente de trabalho que estimula o trabalho em equipe e constrói confiança3100a empresa fornece apoio técnico-administrativo para equipes de projeto.3070a empresa encoraja as equipes de projeto a assumir riscos calculados para melhorar o desempenho dos projetos3080a empresa cria um ambiente de trabalho que apóia a realização pessoal e profissional

143 143

144 APÊNDICE V: MODELOS DE DOCUMENTOS 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 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 146 Solicitação de mudanças <Nome-Empresa> Projeto: <Nome-Projeto>Solicitação de mudançaselaborado Por: <Nome e Função>Aprovador 1 (Empresa): <Assinatura>Data: Número Data Solicitante Mudança solicitada <Especificar a mudança solicitas> Justificativa <Especificar a justificativa e motivos da mudança> Avaliação dos impactos: Ação recomendada <Especificar a ação a ser tomada>

147 147

148 148 Lições aprendidas <Nome-Empresa> Projeto: <Nome-Projeto>Lições aprendidaselaborado Por: <Nome e Função>Aprovador 1 (Empresa): <Assinatura>Data:

149 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 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 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 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ças Processo 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 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 / Quantidade (Horas) Sub-total (R$) Orça Valor Hora (R$) Custo do projeto Adicional de Risco para Valor Esperado Reserva Gerencial / Taxa de Administração 5% Custo Final mento por Use Case<local>, em de de ASSINATURAS <principais envolvidos>

154 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 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 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 157 Planilha de Acompanhamento <Nome-Empresa> Projeto: <Nome-Projeto> Planilha de Acompanhamento Revisado Por: <Nome e Função> Aprovador 1 (Empresa): <Assinatura> Data: Aprovador 2 (Cliente): <Assinatura> Data: Ação Implementada Ocorrência Resposta Data da Ocorrência Responsável pelo Registro

158 158

159 Recursos Humanos Matriz de responsabilidades

160 Comunicação Relatório de Não-conformidades

161 Riscos Levantamento de riscos <Nome-Empresa> Projeto: <Nome-Projeto> Planilha de Acompanhamento Data: Responsável Id Risco Área Probabilidade Impacto Financeiro Impacto em Dias

162 162 Mitigação de Riscos <Nome-Empresa> Projeto: <Nome-Projeto> Planilha de Acompanhamento Data: Id Risco Ação Responsável Prazo

163 Aquisições Declaração de Trabalho <Nome-Empresa> Projeto: <Nome-Projeto>Declaração de trabalhoelaborado Por: <Nome e Função>Aprovador 1 (Empresa): <Assinatura>Data: Necessidade <Especificar de forma sucinta a necessidade de aquisição> Objetivos <Especificar os objetivos da requisição> Escopo <Detalhar o escopo da necessidade, expandido e especificando o detalhamento já inserido na WBS> Restrições <Inserir todas as restrições do entregável, sejam técnicas, sejam de prazo> Premissas <Inserir todas as premissas do entregável> Entregáveis <Inserir todos os produtos e objetivos que deverão ser entregues> Critérios de aceite <Inserir todas os critérios de avaliação do entregável e para a sua aceitação> Matriz de responsabilidades <Inserir os nomes do Gerente do Projeto, do Diretor técnico e do responsável por compras>

164 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-orbuy> 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 APÊNDICE VI: QUESTIONÁRIO RESPONDIDO PELA EMPRESA N. Pergunta Descrição 1 A sua organizaçao estabelece e usa padroes de processos de documentacao para a iniciaçao do projeto? 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? 15 Sua organização estabelece e analisa métricas para serem utilizadas no acompanhamento da fase de planejamento de escopo? 16 Sua organização estabelece e analisa métricas para serem utilizadas no acompanhamento da fase de planejamento de tempo? 17 Sua organização estabelece e analisa métricas para serem utilizadas no acompanhamento da fase de planejamento de custo? 18 Sua organização estabelece e analisa métricas para serem utilizadas no acompanhamento da fase de planejamento de qualidade? 19 Sua organização estabelece e analisa métricas para serem utilizadas no acompanhamento da fase de planejamento das aquisições? 20 Sua organização estabelece e analisa métricas para serem utilizadas no acompanhamento da fase de planejamento de Recursos Humanos? 21 Sua organização estabelece e analisa métricas para serem utilizadas no acompanhamento da fase de planejamento de Riscos? 22 Sua organização estabelece e analisa métricas para serem utilizadas no acompanhamento da fase de planejamento de Controle de Mudanças? 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? 25 Sua organização aplica controles no acompanhamento da fase de planejamento de tempo? Nota (0 a 5)

166 166 N. Pergunta Descrição 26 Sua organização aplica controles no acompanhamento da fase de planejamento de custo? 27 Sua organização aplica controles no acompanhamento da fase de planejamento de qualidade? 28 Sua organização aplica controles no acompanhamento da fase de planejamento das aquisições? 29 Sua organização aplica controles no acompanhamento da fase de planejamento de Recursos Humanos? 30 Sua organização aplica controles no acompanhamento da fase de planejamento de Riscos? 31 Sua organização aplica controles no acompanhamento da fase de planejamento de Controle de Mudanças? 32 A organização segue metodologia e procedimentos documentados para Gerência de Projetos? 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? 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? 38 Existe um processo formal para definir se projetos serão ou não executados, se submeterá proposta? 39 A organização aplica um processo formal de acompanhamento dos riscos durante a execução do projeto? 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? 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? 47 É feita a coleta de informações sobre a correção das atividades que foram estimadas para o projeto? 48 São implementadas melhorias na estimativa de atividades dos projetos baseandose em informações coletadas em projetos anteriores? 49 Há um procedimento de controle de mudanças de escopo durante a execução do projeto? Nota (0 a 5) 50 O procedimento de controle de mudanças de escopo durante a execução do

167 167 N. Pergunta projeto é aplicado? Descrição 51 É feita uma estimativa de problemas que poderão surgir sobre o escopo do projeto? 52 É feita a coleta de informações sobre problemas surgidos de escopo mal definido ou de mudanças de escopo? 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? 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? 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? 59 É feita a coleta de informações sobre problemas surgidos de custos mal definidos? 60 São implementadas melhorias na estimativa de custos dos projetos baseando-se em informações coletadas em projetos anteriores? 61 É feita a coleta de informações sobre problemas surgidos na elaboração de relatórios de desempenho? 62 São implementadas melhorias na elaboração de relatório de desempenho baseando-se em informações coletadas em projetos anteriores? 63 É feita a coleta de informações sobre a ocorrência de riscos e as respostas dadas durante a execução do projeto? 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? 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? 68 São implementadas melhorias no processo de encerramento do projeto baseandose em informações coletadas em projetos anteriores? 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? 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? Nota (0 a 5)

168 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. 169 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 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 171 (a) VIEIRA, Marconi Fábio. Gerenciamento de Projetos de Tecnologia da Informação. Rio de Janeiro: (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 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]

Gerência de Projetos de Software CMM & PMBOK

Gerência de Projetos de Software CMM & PMBOK Gerência de Projetos de Software CMM & PMBOK http://www.sei.cmu.edu/ Prefácio do CMM Após várias décadas de promessas não cumpridas sobre ganhos de produtividade e qualidade na aplicação de novas metodologias

Leia mais

Fundamentos do Modelo Prado-MMGP

Fundamentos do Modelo Prado-MMGP Fundamentos do Modelo Prado-MMGP Darci Prado O modelo Prado-MMGP (Modelo de Maturidade em Gerenciamento de Projetos) foi lançado em dezembro de 2002 e reflete a experiência com o tema, de mais de quarenta

Leia mais

Gerenciamento de Projetos Modulo I Conceitos Iniciais

Gerenciamento de Projetos Modulo I Conceitos Iniciais Gerenciamento de Projetos Modulo I Conceitos Iniciais Prof. Walter Cunha falecomigo@waltercunha.com http://waltercunha.com Bibliografia* Project Management Institute. Conjunto de Conhecimentos em Gerenciamento

Leia mais

Questionário de Avaliação de Maturidade Setorial: Modelo de Maturidade Prado-MMGP

Questionário de Avaliação de Maturidade Setorial: Modelo de Maturidade Prado-MMGP DARCI PRADO Questionário de Avaliação de Maturidade Setorial: Modelo de Maturidade Prado-MMGP Versão 2.0.0 Janeiro 2014 Extraído do Livro "Maturidade em Gerenciamento de Projetos" 3ª Edição (a publicar)

Leia mais

QUESTIONÁRIO DE AVALIAÇÃO DE MATURIDADE

QUESTIONÁRIO DE AVALIAÇÃO DE MATURIDADE MMGP Darci Prado QUESTIONÁRIO DE AVALIAÇÃO DE MATURIDADE Extraído do Livro "Maturidade em Gerenciamento de Projetos" - 1ª Edição Versão do Modelo 1..0-01/Fev/008 - Editora INDG-Tecs - 008 WWW.MATURITYRESEARCH.COM

Leia mais

PROPOSTA UNIFICADORA DE NÍVEIS DE MATURIDADE EM GERENCIAMENTO DE PROJETOS

PROPOSTA UNIFICADORA DE NÍVEIS DE MATURIDADE EM GERENCIAMENTO DE PROJETOS ISSN 1984-9354 PROPOSTA UNIFICADORA DE NÍVEIS DE MATURIDADE EM GERENCIAMENTO DE PROJETOS Debora Athayde Herkenhoff (Latec/UFF) Moacyr Amaral Domingues Figueiredo (Latec/UFF) Gilson Brito de Lima (UFF)

Leia mais

Como concluir um projeto com sucesso?

Como concluir um projeto com sucesso? Como concluir um projeto com sucesso? Luiz Eduardo Cunha, Eng. Professor da FAAP e do IMT 1 Luiz Eduardo Cunha Graduado em Engenharia de Produção EPUSP Pós-Graduado em Gestão do Conhecimento e Inteligência

Leia mais

GPAD Gestão de Projetos em Ambientes Digitais

GPAD Gestão de Projetos em Ambientes Digitais GPAD Gestão de Projetos em Ambientes Digitais Tecnologia e Mídias Digitais PUC SP Prof. Eduardo Savino Gomes 1 Afinal, o que vem a ser Gestão? 2 Gestão/Gerir/Gerenciar Gerenciar, administrar, coordenar

Leia mais

fagury.com.br. PMBoK 2004

fagury.com.br. PMBoK 2004 Este material é distribuído por Thiago Fagury através de uma licença Creative Commons 2.5. É permitido o uso e atribuição para fim nãocomercial. É vedada a criação de obras derivadas sem comunicação prévia

Leia mais

Questionário de Avaliação de Maturidadade MMGP Darci Prado QUESTIONÁRIO DE AVALIAÇÃO DE MATURIDADE

Questionário de Avaliação de Maturidadade MMGP Darci Prado QUESTIONÁRIO DE AVALIAÇÃO DE MATURIDADE MMGP Darci Prado QUESTIONÁRIO DE AVALIAÇÃO DE MATURIDADE Extraído do Livro "Gerenciamento de Programas e Projetos nas Organizações" 4ª Edição (a ser lançada) Autor: Darci Prado Editora INDG-Tecs - 1999-2006

Leia mais

O MODELO PRADO-MMGP V4

O MODELO PRADO-MMGP V4 O MODELO PRADO-MMGP V4 Existem, atualmente, diversos modelos de maturidade para gerenciamento de projetos. Todos eles apresentam cinco níveis, mas diferem um pouco no conteúdo de cada nível [1,4,5]. Além

Leia mais

Pesquisa realizada com os participantes do 12º Seminário Nacional de Gestão de Projetos. Apresentação

Pesquisa realizada com os participantes do 12º Seminário Nacional de Gestão de Projetos. Apresentação Pesquisa realizada com os participantes do de Apresentação O perfil do profissional de Projetos Pesquisa realizada durante o 12 Seminário Nacional de, ocorrido em 2009, traça um importante perfil do profissional

Leia mais

Metodologia de Gerenciamento de Projetos e Captação de Recursos. Secretaria das Cidades. Secretaria do Meio Ambiente e Recursos Hídricos

Metodologia de Gerenciamento de Projetos e Captação de Recursos. Secretaria das Cidades. Secretaria do Meio Ambiente e Recursos Hídricos Metodologia de Gerenciamento de Projetos e Captação de Recursos Secretaria das Cidades Secretaria do Meio Ambiente e Recursos Hídricos Evolução da Administração no Setor Público Melhores práticas de gestão

Leia mais

Exercícios: Governança de TI Prof. Walter Cunha http://www.waltercunha.com PRIMEIRA BATERIA. PMBoK

Exercícios: Governança de TI Prof. Walter Cunha http://www.waltercunha.com PRIMEIRA BATERIA. PMBoK Exercícios: Governança de TI Prof. Walter Cunha http://www.waltercunha.com PRIMEIRA BATERIA PMBoK 1. (FCC/ANALISTA-MPU 2007) De acordo com o corpo de conhecimento da gerência de projetos, as simulações

Leia mais

FINANÇAS EM PROJETOS DE TI

FINANÇAS EM PROJETOS DE TI FINANÇAS EM PROJETOS DE TI 2012 Material 1 Prof. Luiz Carlos Valeretto Jr. 1 E-mail valeretto@yahoo.com.br Objetivo Objetivos desta disciplina são: reconhecer as bases da administração financeira das empresas,

Leia mais

Carlos Henrique Santos da Silva

Carlos Henrique Santos da Silva GOVERNANÇA DE TI Carlos Henrique Santos da Silva Mestre em Informática em Sistemas de Informação UFRJ/IM Certificado em Project Management Professional (PMP) PMI Certificado em IT Services Management ITIL

Leia mais

Gestão da Tecnologia da Informação

Gestão da Tecnologia da Informação TLCne-051027-P0 Gestão da Tecnologia da Informação Disciplina: Governança de TI São Paulo, Outubro de 2012 0 Sumário TLCne-051027-P1 Conteúdo desta Aula Abordar o domínio Adquirir e Implementar e todos

Leia mais

Conteúdo. Apresentação do PMBOK. Projeto 29/07/2015. Padrões de Gerenciamento de Projetos. Fase 01 1.PMBOK e PMI. 2. Conceitos 3.

Conteúdo. Apresentação do PMBOK. Projeto 29/07/2015. Padrões de Gerenciamento de Projetos. Fase 01 1.PMBOK e PMI. 2. Conceitos 3. 02m Conteúdo Apresentação do PMBOK Brasília, 25 de Junho de 2015 Fase 01 1.PMBOK e PMI 2. Conceitos 3.Processos Fase 02 4. Áreas de Conhecimento 10m Gerenciamento de Projetos Projeto A manifestação da

Leia mais

GESTÃO DA QUALIDADE DE SOFTWARE

GESTÃO DA QUALIDADE DE SOFTWARE GESTÃO DA QUALIDADE DE SOFTWARE Fernando L. F. Almeida falmeida@ispgaya.pt Principais Modelos Capability Maturity Model Integration (CMMI) Team Software Process and Personal Software Process (TSP/PSP)

Leia mais

Gerenciamento de Projetos

Gerenciamento de Projetos Gerenciamento de Projetos (ref. capítulos 1 a 3 PMBOK) TC045 Gerenciamento de Projetos Sergio Scheer - scheer@ufpr.br O que é Gerenciamento de Projetos? Aplicação de conhecimentos, habilidades, ferramentas

Leia mais

A IMPORTÂNCIA DO TESTE DE SOFTWARE PARA A QUALIDADE DO PROJETO

A IMPORTÂNCIA DO TESTE DE SOFTWARE PARA A QUALIDADE DO PROJETO A IMPORTÂNCIA DO TESTE DE SOFTWARE PARA A QUALIDADE DO PROJETO Autora: LUCIANA DE BARROS ARAÚJO 1 Professor Orientador: LUIZ CLAUDIO DE F. PIMENTA 2 RESUMO O mercado atual está cada vez mais exigente com

Leia mais

Trilhas Técnicas SBSI - 2014

Trilhas Técnicas SBSI - 2014 brunoronha@gmail.com, germanofenner@gmail.com, albertosampaio@ufc.br Brito (2012), os escritórios de gerenciamento de projetos são importantes para o fomento de mudanças, bem como para a melhoria da eficiência

Leia mais

GERENCIAMENTO DE PROJETOS EM UM ESCRITÓRIO DE ARQUITETURA: VISÃO TRADICIONAL X NEGÓCIOS BASEADOS EM PROJETOS

GERENCIAMENTO DE PROJETOS EM UM ESCRITÓRIO DE ARQUITETURA: VISÃO TRADICIONAL X NEGÓCIOS BASEADOS EM PROJETOS GERENCIAMENTO DE PROJETOS EM UM ESCRITÓRIO DE ARQUITETURA: VISÃO TRADICIONAL X NEGÓCIOS BASEADOS EM PROJETOS Ana Carolina Freitas Teixeira¹ RESUMO O gerenciamento de projetos continua crescendo e cada

Leia mais

DESENVOLVENDO A MATURIDADE EM GESTÃO DE PROJETOS NAS EMPRESAS ATRAVÉS DA IMPLANTAÇÃO DO PMO 1

DESENVOLVENDO A MATURIDADE EM GESTÃO DE PROJETOS NAS EMPRESAS ATRAVÉS DA IMPLANTAÇÃO DO PMO 1 DESENVOLVENDO A MATURIDADE EM GESTÃO DE PROJETOS NAS EMPRESAS ATRAVÉS DA IMPLANTAÇÃO DO PMO 1 Marcelo Campolina de Castro 2 Resumo Com o novo cenário econômico, muitas empresas estão investindo alto na

Leia mais

ESCRITÓRIO RIO DE PROJETOS

ESCRITÓRIO RIO DE PROJETOS PMO PROJETOS PROCESSOS MELHORIA CONTÍNUA PMI SCRUM COBIT ITIL LEAN SIX SIGMA BSC ESCRITÓRIO RIO DE PROJETOS DESAFIOS CULTURAIS PARA IMPLANTAÇÃO DANIEL AQUERE DE OLIVEIRA, PMP, MBA daniel.aquere@pmpartner.com.br

Leia mais

14 Os principais documentos de um projeto são: o termo de. 15 Elemento integrante do gerenciamento do escopo do projeto,

14 Os principais documentos de um projeto são: o termo de. 15 Elemento integrante do gerenciamento do escopo do projeto, De acordo com o comando a que cada um dos itens de 1 a 70 se refira, marque, na folha de respostas, para cada item: o campo designado com o código C, caso julgue o item CERTO; ou o campo designado com

Leia mais

No que se refere a conceitos básicos do gerenciamento de projetos, segundo o PMBoK, julgue os itens a seguir.

No que se refere a conceitos básicos do gerenciamento de projetos, segundo o PMBoK, julgue os itens a seguir. De acordo com o comando a que cada um dos itens de 1 a 70 se refira, marque, na folha de respostas, para cada item: o campo designado com o código C, caso julgue o item CERTO; ou o campo designado com

Leia mais

(C) A-C-E-F-H (D) A-G-F-H (E) A-G-I. Exercícios: Governança de TI Walter Cunha PRIMEIRA BATERIA. PMBoK COBIT

(C) A-C-E-F-H (D) A-G-F-H (E) A-G-I. Exercícios: Governança de TI Walter Cunha PRIMEIRA BATERIA. PMBoK COBIT Exercícios: Governança de TI Walter Cunha PRIMEIRA ATERIA (C) A-C-E-F-H (D) A-G-F-H (E) A-G-I PMoK 1. (FCC/ANALISTA-MPU 2007) De acordo com o corpo de conhecimento da gerência de projetos, as simulações

Leia mais

Questionário de avaliação de Práticas X Resultados de projetos - Carlos Magno Xavier (magno@beware.com.br)

Questionário de avaliação de Práticas X Resultados de projetos - Carlos Magno Xavier (magno@beware.com.br) Obrigado por acessar esta pesquisa. Sei como é escasso o seu tempo, mas tenha a certeza que você estará contribuindo não somente para uma tese de doutorado, mas também para a melhoria das práticas da Comunidade

Leia mais

Objetivos da aula. Planejamento, Execução e Controle de Projetos de Software. O que é um plano de projeto? O que é um projeto?

Objetivos da aula. Planejamento, Execução e Controle de Projetos de Software. O que é um plano de projeto? O que é um projeto? Planejamento, Execução e Controle de Projetos de Software. Objetivos da aula 1) Dizer o que é gerenciamento de projetos e a sua importância; 2) Identificar os grupos de processos do gerenciamento de projetos

Leia mais

Programa do Curso de Pós-Graduação Lato Sensu MBA em Engenharia de Software Orientada a Serviços (SOA)

Programa do Curso de Pós-Graduação Lato Sensu MBA em Engenharia de Software Orientada a Serviços (SOA) Programa do Curso de Pós-Graduação Lato Sensu MBA em Engenharia de Software Orientada a Serviços (SOA) Apresentação O programa de Pós-graduação Lato Sensu em Engenharia de Software Orientada a Serviços

Leia mais

O Gerenciamento de Projetos na abordagem do

O Gerenciamento de Projetos na abordagem do Seminário de Desenvolvimento de Gestores de Programas e Projetos Fórum QPC O Gerenciamento de Projetos na abordagem do PMI - Project Management Institute Marco Antônio Kappel Ribeiro Presidente do PMI-RS

Leia mais

Gerenciamento de Projetos Modulo I Conceitos Iniciais

Gerenciamento de Projetos Modulo I Conceitos Iniciais Gerenciamento de Projetos Modulo I Conceitos Iniciais Prof. Walter Cunha falecomigo@waltercunha.com http://waltercunha.com Bibliografia* Project Management Institute. Conjunto de Conhecimentos em Gerenciamento

Leia mais

Lista de Exercícios - COBIT 5

Lista de Exercícios - COBIT 5 Lista de Exercícios - COBIT 5 1. O COBIT 5 possui: a) 3 volumes, 7 habilitadores, 5 princípios b) 3 volumes, 5 habilitadores, 7 princípios c) 5 volumes, 7 habilitadores, 5 princípios d) 5 volumes, 5 habilitadores,

Leia mais

CobiT: Visão Geral e domínio Monitorar e Avaliar. Daniel Baptista Dias Ernando Eduardo da Silva Leandro Kaoru Sakamoto Paolo Victor Leite e Posso

CobiT: Visão Geral e domínio Monitorar e Avaliar. Daniel Baptista Dias Ernando Eduardo da Silva Leandro Kaoru Sakamoto Paolo Victor Leite e Posso CobiT: Visão Geral e domínio Monitorar e Avaliar Daniel Baptista Dias Ernando Eduardo da Silva Leandro Kaoru Sakamoto Paolo Victor Leite e Posso CobiT O que é? Um framework contendo boas práticas para

Leia mais

MMGP: UM MODELO BRASILEIRO DE MATURIDADE EM GERENCIAMENTO DE PROJETOS

MMGP: UM MODELO BRASILEIRO DE MATURIDADE EM GERENCIAMENTO DE PROJETOS MMGP: UM MODELO BRASILEIRO DE MATURIDADE EM GERENCIAMENTO DE PROJETOS Darci Prado - Introdução Maturida em Gerenciamento Projetos (GP) está na moda: inúmeros artigos têm surgido nas revistas especializadas,

Leia mais

Teoria e Prática. Totalmente de acordo com a 4 a Edição/2009. Rosaldo de Jesus Nocêra, PMP, PMI-SP, MCTS. do PMBOK do PMI. Acompanha o livro:

Teoria e Prática. Totalmente de acordo com a 4 a Edição/2009. Rosaldo de Jesus Nocêra, PMP, PMI-SP, MCTS. do PMBOK do PMI. Acompanha o livro: Gerenciamento de Projetos Teoria e Prática Totalmente de acordo com a 4 a Edição/2009 do PMBOK do PMI Acompanha o livro: l CD com mais de 70 formulários exemplos indicados pelo PMI e outros desenvolvidos

Leia mais

Gerenciamento de Projetos

Gerenciamento de Projetos Gerenciamento de Projetos PMI, PMP e PMBOK PMI (Project Management Institute) Estabelecido em 1969 e sediado na Filadélfia, Pensilvânia EUA, o PMI é a principal associação mundial, sem fins lucrativos,

Leia mais

Escritório de Gerenciamento de Projetos ( Project Management Office PMO)

Escritório de Gerenciamento de Projetos ( Project Management Office PMO) MBA em Gestão de Projetos Escritório de Gerenciamento de Projetos ( Project Management Office PMO) Flávio Feitosa Costa, MSc. PMP (flaviopmp@gmail.com) MBA em Gerência de Projetos Escritório de Gerenciamento

Leia mais

Modelo de Maturidade Organizacional de Gerência de Projetos. Organizational Project Management Maturity Model - OPM3

Modelo de Maturidade Organizacional de Gerência de Projetos. Organizational Project Management Maturity Model - OPM3 Modelo de Maturidade Organizacional de Gerência de Projetos Introdução Organizational Project Management Maturity Model - OPM3 Um trabalho voluntário A idéia de um modelo não é novidade, as organizações

Leia mais

C O B I T. Gerenciamento dos Riscos Mitigação. Aceitação. Transferência. Evitar/Eliminar.

C O B I T. Gerenciamento dos Riscos Mitigação. Aceitação. Transferência. Evitar/Eliminar. C O B I T Evolução Estratégica A) Provedor de Tecnologia Gerenciamento de Infra-estrutura de TI (ITIM) B) Provedor de Serviços Gerenciamento de Serviços de TI (ITSM) C) Parceiro Estratégico Governança

Leia mais

A Maturidade Organizacional em Gerenciamento de Projetos (OPM3 ) de Informática em Saúde

A Maturidade Organizacional em Gerenciamento de Projetos (OPM3 ) de Informática em Saúde A Maturidade Organizacional em Gerenciamento de Projetos (OPM3 ) de Informática em Saúde Luis Augusto dos Santos 1, Heimar de Fátima Marin 2 1 Engenheiro Eletricista, membro do NIEn e pós-graduando pela

Leia mais

Maturidade Organizacional: Melhorando a Qualidade do Gerenciamento de Projetos Leonardo Luiz Barbosa Vieira Cruciol

Maturidade Organizacional: Melhorando a Qualidade do Gerenciamento de Projetos Leonardo Luiz Barbosa Vieira Cruciol Maturidade Organizacional: Melhorando a Qualidade do Gerenciamento de Projetos Leonardo Luiz Barbosa Vieira Cruciol Resumo. O gerenciamento de projetos tem se tornado, durante os últimos anos, alvo de

Leia mais

MASTER IN PROJECT MANAGEMENT

MASTER IN PROJECT MANAGEMENT MASTER IN PROJECT MANAGEMENT PROJETOS E COMUNICAÇÃO PROF. RICARDO SCHWACH MBA, PMP, COBIT, ITIL Atividade 1 Que modelos em gestão de projetos estão sendo adotados como referência nas organizações? Como

Leia mais

Unidade I GERENCIAMENTO DE. Profa. Celia Corigliano

Unidade I GERENCIAMENTO DE. Profa. Celia Corigliano Unidade I GERENCIAMENTO DE PROJETOS DE TI Profa. Celia Corigliano Objetivo Estimular o aluno no aprofundamento do conhecimento das técnicas de gestão profissional de projetos do PMI. Desenvolver em aula

Leia mais

Resultados alcançados com a Ferramenta Channel em implementação de sucesso da Gerência de Projetos no nível G de maturidade do MR-MPS

Resultados alcançados com a Ferramenta Channel em implementação de sucesso da Gerência de Projetos no nível G de maturidade do MR-MPS Resultados alcançados com a Ferramenta Channel em implementação de sucesso da Gerência de Projetos no nível G de maturidade do MR-MPS Mauricio Fiorese 1, Alessandra Zoucas 2 e Marcello Thiry 2 1 JExperts

Leia mais

Sistemas de Informação Empresarial

Sistemas de Informação Empresarial Sistemas de Informação Empresarial Governança de Tecnologia da Informação parte 2 Fonte: Mônica C. Rodrigues Padrões e Gestão de TI ISO,COBIT, ITIL 3 International Organization for Standardization d -

Leia mais

Gerenciamento de Projetos Web. Professor: Guilherme Luiz Frufrek Email: frufrek@utfpr.edu.br http://paginapessoal.utfpr.edu.

Gerenciamento de Projetos Web. Professor: Guilherme Luiz Frufrek Email: frufrek@utfpr.edu.br http://paginapessoal.utfpr.edu. Gerenciamento de Projetos Web Professor: Guilherme Luiz Frufrek Email: frufrek@utfpr.edu.br http://paginapessoal.utfpr.edu.br/frufrek Possui Especialização em Engenharia de Software e Banco de Dados pela

Leia mais

BENEFÍCIOS DO GERENCIAMENTO DE PROJETOS. Por Maria Luiza Panchihak

BENEFÍCIOS DO GERENCIAMENTO DE PROJETOS. Por Maria Luiza Panchihak BENEFÍCIOS DO GERENCIAMENTO DE PROJETOS Por Maria Luiza Panchihak Este artigo apresenta os benefícios do gerenciamento de projetos e mostra a importância desse processo, dentro de uma organização, para

Leia mais

PROCESSO DE IMPLANTAÇÃO DO PMBOK EM ORGANIZAÇÕES DE SOFTWARE PROPOSTA DE TRABALHO DE GRADUAÇÃO

PROCESSO DE IMPLANTAÇÃO DO PMBOK EM ORGANIZAÇÕES DE SOFTWARE PROPOSTA DE TRABALHO DE GRADUAÇÃO UNIVERSIDADE FEDERAL DE PERNAMBUCO GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO CENTRO DE INFORMÁTICA PROCESSO DE IMPLANTAÇÃO DO PMBOK EM ORGANIZAÇÕES DE SOFTWARE PROPOSTA DE TRABALHO DE GRADUAÇÃO Aluno: Marcus

Leia mais

Pesquisa de Maturidade do GERAES. Data de aplicação: 21/02/08

Pesquisa de Maturidade do GERAES. Data de aplicação: 21/02/08 Pesquisa de Maturidade do GERAES Data de aplicação: 21/02/08 Pesquisa de Maturidade Metodologia MPCM / Darci Prado Disponível em www.maturityresearch.com Metodologia da pesquisa 5 níveis e 6 dimensões

Leia mais

Gerenciamento de Aquisições em Projetos. Palestrante: Carlos Magno da Silva Xavier, M.Sc., PMP magno@beware.com.br

Gerenciamento de Aquisições em Projetos. Palestrante: Carlos Magno da Silva Xavier, M.Sc., PMP magno@beware.com.br Gerenciamento de Aquisições em Projetos Palestrante: Carlos Magno da Silva Xavier, M.Sc., PMP magno@beware.com.br Agenda I - O Gerenciamento de Aquisições em Projetos II - A Importância do Gerenciamento

Leia mais

BOAS PRÁTICAS EM GESTÃO DE CONHECIMENTO PARA MELHORAR RESULTADOS DE PROJETOS

BOAS PRÁTICAS EM GESTÃO DE CONHECIMENTO PARA MELHORAR RESULTADOS DE PROJETOS BOAS PRÁTICAS EM GESTÃO DE CONHECIMENTO PARA MELHORAR RESULTADOS DE PROJETOS Marcela Souto Castro (UFF ) idearconsultoria@gmail.com Jose Rodrigues de Farias Filho (UFF ) rodrigues@labceo.uff.br Arnaldo

Leia mais

Programa do Curso de Pós-Graduação Lato Sensu MBA em Gestão de Tecnologia da Informação

Programa do Curso de Pós-Graduação Lato Sensu MBA em Gestão de Tecnologia da Informação Programa do Curso de Pós-Graduação Lato Sensu MBA em Gestão de Tecnologia da Informação Apresentação O programa de Pós-graduação Lato Sensu em Gestão de Tecnologia da Informação tem por fornecer conhecimento

Leia mais

METODOLOGIA HSM Centrada nos participantes com professores com experiência executiva, materiais especialmente desenvolvidos e infraestrutura tecnológica privilegiada. O conteúdo exclusivo dos especialistas

Leia mais

CARACTERÍSTICAS DE UM PROJETO

CARACTERÍSTICAS DE UM PROJETO CARACTERÍSTICAS DE UM PROJETO Temporário: significa que cada projeto tem um início e um fim muito bem definidos. Um projeto é fundamentalmente diferente: porque ele termina quando seus objetivos propostos

Leia mais

A estrutura do gerenciamento de projetos

A estrutura do gerenciamento de projetos A estrutura do gerenciamento de projetos Introdução O Guia do Conhecimento em Gerenciamento de Projetos (Guia PMBOK ) é uma norma reconhecida para a profissão de gerenciamento de projetos. Um padrão é

Leia mais

8/3/2009. Empreendimento temporário que tem por finalidade criar um produto, serviço ou resultado exclusivo.

8/3/2009. Empreendimento temporário que tem por finalidade criar um produto, serviço ou resultado exclusivo. FAE S.J. dos Pinhais Projeto e Desenvolvimento de Software Conceitos Básicos Prof. Anderson D. Moura O que é um projeto? Conjunto de atividades que: 1. Objetivo específico que pode ser concluído 2. Tem

Leia mais

UNIVERSIDADE DO ESTADO DE SANTA CATARINA UDESC CENTRO DE EDUCAÇÃO SUPERIOR DO ALTO VALE DO ITAJAÍ CEAVI DIREÇÃO DE ENSINO DEN PLANO DE ENSINO

UNIVERSIDADE DO ESTADO DE SANTA CATARINA UDESC CENTRO DE EDUCAÇÃO SUPERIOR DO ALTO VALE DO ITAJAÍ CEAVI DIREÇÃO DE ENSINO DEN PLANO DE ENSINO UNIVERSIDADE DO ESTADO DE SANTA CATARINA UDESC CENTRO DE EDUCAÇÃO SUPERIOR DO ALTO VALE DO ITAJAÍ CEAVI DIREÇÃO DE ENSINO DEN DEPARTAMENTO: SISTEMAS DE INFORMAÇÃO PLANO DE ENSINO DISCIPLINA: GERÊNCIA DE

Leia mais

CURSO DE PÓS-GRADUAÇÃO LATO SENSU (ESPECIALIZAÇÃO) MBA em Gerenciamento de Projetos Coordenação Acadêmica: Dr. André Valle

CURSO DE PÓS-GRADUAÇÃO LATO SENSU (ESPECIALIZAÇÃO) MBA em Gerenciamento de Projetos Coordenação Acadêmica: Dr. André Valle CURSO DE PÓS-GRADUAÇÃO LATO SENSU (ESPECIALIZAÇÃO) MBA em Gerenciamento de Projetos Coordenação Acadêmica: Dr. André Valle APRESENTAÇÃO A FGV é uma instituição privada sem fins lucrativos, fundada em 1944,

Leia mais

Declaração de trabalho do projeto. Caso de negócio. Fatores ambientais da empresa. Estratégia de gerenciamento das partes interessadas.

Declaração de trabalho do projeto. Caso de negócio. Fatores ambientais da empresa. Estratégia de gerenciamento das partes interessadas. 30 Estratégia de gerenciamento das partes interessadas. Eles serão descritos nas subseções a seguir. Declaração de trabalho do projeto A declaração de trabalho do projeto descreve o produto, serviço ou

Leia mais

Universidade de Brasília Faculdade de Ciência da Informação Curso de Arquivologia Profa. Lillian Alvares

Universidade de Brasília Faculdade de Ciência da Informação Curso de Arquivologia Profa. Lillian Alvares Universidade de Brasília Faculdade de Ciência da Informação Curso de Arquivologia Profa. Lillian Alvares O Project Management Institute é uma entidade sem fins lucrativos voltada ao Gerenciamento de Projetos.

Leia mais

e PMA Consultoria www.pma.com.br

e PMA Consultoria www.pma.com.br e PMA Consultoria www.pma.com.br 1 MATURIDADE EM GERENCIAMENTO DE PROJETOS ROTEIRO: Necessidades Atuais A Plataforma Modelo de Maturidade Alguns Valores Maturidade e Sucesso Apoio INDG Gestão de mudanças

Leia mais

PMI-SP PMI-SC PMI-RS PMI PMI-PR PMI-PE

PMI-SP PMI-SC PMI-RS PMI PMI-PR PMI-PE ESTUDO DE BENCHMARKING EM GERENCIAMENTO DE PROJETOS 2009 Brasil Uma realização dos Chapters Brasileiros do PMI - Project Management Institute PMI-SP PMI-RJ PMI-AM PMI-SC PMI-BA ANEXO 1 PMI-RS PMI PMI-CE

Leia mais

Gerenciamento de Projetos de TI

Gerenciamento de Projetos de TI Gerenciamento de Projetos de TI Práticas do PMBOK v4 e controles do COBIT v4.1 aplicados à Tecnologia da Informação. Objetivo Este curso tem como objetivo consolidar conhecimentos sobre as melhores práticas

Leia mais

Universidade de Brasília. Departamento de Ciência da Informação e Documentação. Prof a.:lillian Alvares

Universidade de Brasília. Departamento de Ciência da Informação e Documentação. Prof a.:lillian Alvares Universidade de Brasília Departamento de Ciência da Informação e Documentação Prof a.:lillian Alvares Fóruns óu s/ Listas de discussão Espaços para discutir, homogeneizar e compartilhar informações, idéias

Leia mais

PÓS - GRADUAÇÃO LATO SENSU ESPECIALIZAÇÃO MBA EM GERENCIAMENTO DE PROJETOS

PÓS - GRADUAÇÃO LATO SENSU ESPECIALIZAÇÃO MBA EM GERENCIAMENTO DE PROJETOS PÓS - GRADUAÇÃO LATO SENSU ESPECIALIZAÇÃO MBA EM GERENCIAMENTO DE PROJETOS 2014 1. COORDENAÇÃO ACADÊMICA Prof.º André Bittencourt do Valle 2. FUNDAÇÃO GETULIO VARGAS É uma instituição de direito privado,

Leia mais

ASPECTOS GERAIS DE PROJETOS

ASPECTOS GERAIS DE PROJETOS ASPECTOS GERAIS DE PROJETOS O que é PROJETO Um empreendimento com começo e fim definidos, dirigido por pessoas, para cumprir objetivos estabelecidos dentro de parâmetros de custo, tempo e especificações.

Leia mais

QUAL O ESCOPO ADEQUADO DE UM PROJETO DE MELHORIA DA MATURIDADE DO GERENCIAMENTO DE PROJETOS?

QUAL O ESCOPO ADEQUADO DE UM PROJETO DE MELHORIA DA MATURIDADE DO GERENCIAMENTO DE PROJETOS? QUAL O ESCOPO ADEQUADO DE UM PROJETO DE MELHORIA DA MATURIDADE DO GERENCIAMENTO DE PROJETOS? APRESENTAÇÃO: CARLOS MAGNO DA SILVA XAVIER magno@beware.com.br www.beware.com.br O QUE ESSES EVENTOS TÊM EM

Leia mais

Pesquisa realizada com os participantes do 16º Seminário Nacional de Gestão de Projetos APRESENTAÇÃO

Pesquisa realizada com os participantes do 16º Seminário Nacional de Gestão de Projetos APRESENTAÇÃO Pesquisa realizada com os participantes do de APRESENTAÇÃO O perfil do profissional de projetos Pesquisa realizada durante o 16 Seminário Nacional de, ocorrido em Belo Horizonte em Junho de, apresenta

Leia mais

Definição do Framework de Execução de Processos Spider-PE

Definição do Framework de Execução de Processos Spider-PE Definição do Framework de Execução de Processos Spider-PE 1. INTRODUÇÃO 1.1 Finalidade Este documento define um framework de execução de processos de software, denominado Spider-PE (Process Enactment),

Leia mais

Gerência de Projetos CMMI & PMBOK

Gerência de Projetos CMMI & PMBOK Gerência de Projetos CMMI & PMBOK Uma abordagem voltada para a qualidade de processos e produtos Prof. Paulo Ricardo B. Betencourt pbetencourt@urisan.tche.br Adaptação do Original de: José Ignácio Jaeger

Leia mais

Qualidade de Software: Visão Geral

Qualidade de Software: Visão Geral Qualidade de Software: Visão Geral Engenharia de Software 1 Aula 05 Qualidade de Software Existem muitas definições de qualidade de software propostas na literatura, sob diferentes pontos de vista Qualidade

Leia mais

Fatores Críticos de Sucesso em GP

Fatores Críticos de Sucesso em GP Fatores Críticos de Sucesso em GP Paulo Ferrucio, PMP pferrucio@hotmail.com A necessidade das organizações de maior eficiência e velocidade para atender as necessidades do mercado faz com que os projetos

Leia mais

Controle de métricas no processo de desenvolvimento de software através de uma ferramenta de workflow

Controle de métricas no processo de desenvolvimento de software através de uma ferramenta de workflow Controle de métricas no processo de desenvolvimento de software através de uma ferramenta de workflow Gustavo Zanini Kantorski, Marcelo Lopes Kroth Centro de Processamento de Dados Universidade Federal

Leia mais

CIÊNCIA DA COMPUTAÇÃO Engenharia de SoftwareLuiz Carlos Aires de Macêdo. Gestão de Projeto de Software

CIÊNCIA DA COMPUTAÇÃO Engenharia de SoftwareLuiz Carlos Aires de Macêdo. Gestão de Projeto de Software Gestão de Projeto de Software Gestão de Projeto de Software: Trata de práticas para entregar um software que respeite os custos, padrões e o tempo. Padrões Custos Engenheiro de Software Projeto de Software

Leia mais

Ciência da Computação ENGENHARIA DE SOFTWARE. Planejamento e Gerenciamento

Ciência da Computação ENGENHARIA DE SOFTWARE. Planejamento e Gerenciamento Ciência da Computação ENGENHARIA DE SOFTWARE Planejamento e Gerenciamento Prof. Claudinei Dias email: prof.claudinei.dias@gmail.com Roteiro Introdução; Pessoas, Produto, Processo e Projeto; Gerência de

Leia mais

Introdução ao BPM e CBOK. Decanato de Planejamento e Orçamento DPO Diretoria de Processos Organizacionais - DPR

Introdução ao BPM e CBOK. Decanato de Planejamento e Orçamento DPO Diretoria de Processos Organizacionais - DPR Introdução ao BPM e CBOK Decanato de Planejamento e Orçamento DPO Diretoria de Processos Organizacionais - DPR BPM CBOK O Guia para o Gerenciamento de Processos de Negócio - Corpo Comum de Conhecimento

Leia mais

CARTILHA DE GERENCIAMENTO DE PROJETOS

CARTILHA DE GERENCIAMENTO DE PROJETOS CARTILHA DE GERENCIAMENTO DE PROJETOS 1ª edição - 2015 ÍNDICE INTRODUÇÃO...03 O QUE É UM PROJETO?...04 O QUE É UM PROGRAMA?...07 ESTUDOS E PROJETOS...08 O QUE É O GERENCIAMENTO DE PROJETOS...09 QUEM É

Leia mais

Módulo: Empreendedorismo Gestão de Projetos. Agenda da Teleaula. Vídeo. Logística 28/8/2012

Módulo: Empreendedorismo Gestão de Projetos. Agenda da Teleaula. Vídeo. Logística 28/8/2012 Logística Profª. Paula Emiko Kuwamoto Módulo: Empreendedorismo Gestão de Projetos Agenda da Teleaula Reforçar a importância dos projetos no cenário atual. Apresentar os principais conceitos envolvendo

Leia mais

Gerenciamento de Projetos

Gerenciamento de Projetos Gerenciamento de Projetos Grupo de Consultores em Governança de TI do SISP 20/02/2013 1 Agenda 1. PMI e MGP/SISP 2. Conceitos Básicos - Operações e Projetos - Gerenciamento de Projetos - Escritório de

Leia mais

UNIVERSIDADE DO ESTADO DE SANTA CATARINA UDESC CENTRO DE EDUCAÇÃO SUPERIOR DO ALTO VALE DO ITAJAÍ CEAVI DIREÇÃO DE ENSINO DEN PLANO DE ENSINO

UNIVERSIDADE DO ESTADO DE SANTA CATARINA UDESC CENTRO DE EDUCAÇÃO SUPERIOR DO ALTO VALE DO ITAJAÍ CEAVI DIREÇÃO DE ENSINO DEN PLANO DE ENSINO Departamento: Disciplina: Pré-Requisitos: - I D E N T I F I C A Ç Ã O Sistemas de Informação Gerência de Projetos (GEP) CH: 72 h/a Curso: Bacharelado em Sistemas de Informação Semestre: 2011/1 Fase: 8ª

Leia mais

Quais são as Balas de Prata no Gerenciamento de Projetos? (Autores: Carlos Magno da Silva Xavier e Alberto Sulaiman Sade Júnior) Resumo

Quais são as Balas de Prata no Gerenciamento de Projetos? (Autores: Carlos Magno da Silva Xavier e Alberto Sulaiman Sade Júnior) Resumo Quais são as Balas de Prata no Gerenciamento de Projetos? (Autores: Carlos Magno da Silva Xavier e Alberto Sulaiman Sade Júnior) Resumo A metáfora bala de prata se aplica a qualquer ação que terá uma extrema

Leia mais

Modelos de Maturidade (CMMI, MPS-BR, PMMM)

Modelos de Maturidade (CMMI, MPS-BR, PMMM) UNEB - UNIVERSIDADE DO ESTADO DA BAHIA DEPARTAMENTO DE CIÊNCIAS EXATAS E DA TERRA - DCET1 COLEGIADO DE SISTEMAS DE INFORMAÇÃO DISCIPLINA: ENGENHARIA DE SOFTWARE PROFESSOR: EDUARDO JORGE Modelos de Maturidade

Leia mais

Análise de Processos do PMBOK em uma Fábrica de Software Um Estudo de Caso

Análise de Processos do PMBOK em uma Fábrica de Software Um Estudo de Caso Análise de Processos do PMBOK em uma Fábrica de Software Um Estudo de Caso Carlos Alberto Rovedder, Gustavo Zanini Kantorski Curso de Sistemas de Informação Universidade Luterana do Brasil (ULBRA) Campus

Leia mais

PMI - PMBoK PMI PROJECT MANAGEMENT INSTITUTE. PMBoK PROJECT MANAGEMENT BODY OF KNOWLEDGE

PMI - PMBoK PMI PROJECT MANAGEMENT INSTITUTE. PMBoK PROJECT MANAGEMENT BODY OF KNOWLEDGE PMI - PMBoK PMI PROJECT MANAGEMENT INSTITUTE PMBoK PROJECT MANAGEMENT BODY OF KNOWLEDGE 1 PMI- Project Management Institute Fundado nos Estudos Unidos em 1969; Instituto sem fins lucrativos, dedicado ao

Leia mais

efagundes com GOVERNANÇA DE TIC Eduardo Mayer Fagundes Aula 3/4

efagundes com GOVERNANÇA DE TIC Eduardo Mayer Fagundes Aula 3/4 GOVERNANÇA DE TIC Eduardo Mayer Fagundes Aula 3/4 1 CobIT Modelo abrangente aplicável para a auditoria e controle de processo de TI, desde o planejamento da tecnologia até a monitoração e auditoria de

Leia mais

UNIVERSIDADE FEDERAL FLUMINENSE PÓS-GRADUAÇÃO EM GERENCIAMENTO DE PROJETOS ROSINA ANGELA PERROTTA DE OLIVEIRA ESTUDO DE CASO:

UNIVERSIDADE FEDERAL FLUMINENSE PÓS-GRADUAÇÃO EM GERENCIAMENTO DE PROJETOS ROSINA ANGELA PERROTTA DE OLIVEIRA ESTUDO DE CASO: UNIVERSIDADE FEDERAL FLUMINENSE LABCEO - NÚCLEO DE COMPETITIVIDADE, ESTRATÉGIA E ORGANIZAÇÕES PÓS-GRADUAÇÃO EM GERENCIAMENTO DE PROJETOS ROSINA ANGELA PERROTTA DE OLIVEIRA ESTUDO DE CASO: AVALIAÇÃO DA

Leia mais

Implementação utilizando as melhores práticas em Gestão de Projetos

Implementação utilizando as melhores práticas em Gestão de Projetos Implementação utilizando as melhores práticas em Gestão de Projetos Objetivo dessa aula é mostrar a importância em utilizar uma metodologia de implantação de sistemas baseada nas melhores práticas de mercado

Leia mais

AVALIAÇÃO DE UM PROCESSO DE IMPLANTAÇÃO DE PRODUTOS DE SOFTWARE QUANTO A SUA ADERÊNCIA AO CMMI FOR SERVICE

AVALIAÇÃO DE UM PROCESSO DE IMPLANTAÇÃO DE PRODUTOS DE SOFTWARE QUANTO A SUA ADERÊNCIA AO CMMI FOR SERVICE AVALIAÇÃO DE UM PROCESSO DE IMPLANTAÇÃO DE PRODUTOS DE SOFTWARE QUANTO A SUA ADERÊNCIA AO CMMI FOR SERVICE Autoria: Natércia Ponte Nogueira, Andreia Rodrigues, Adriano Albuquerque, Alessandro Câmara RESUMO.

Leia mais

3 Gerenciamento de Projetos

3 Gerenciamento de Projetos 34 3 Gerenciamento de Projetos Neste capítulo, será abordado o tema de gerenciamento de projetos, iniciando na seção 3.1 um estudo de bibliografia sobre a definição do tema e a origem deste estudo. Na

Leia mais

CMM - Capability Maturity Model

CMM - Capability Maturity Model Tema da Aula Normas e Padrões de Qualidade em II CMM Prof. Cristiano R R Portella portella@widesoft.com.br CMM - Capability Maturity Model Desenvolvido pelo SEI (Instituto de Engenharia de ) Carnegie Mellon

Leia mais

ALESSANDRO PEREIRA DOS REIS PAULO CESAR CASTRO DE ALMEIDA ENGENHARIA DE SOFTWARE - CAPABILITY MATURITY MODEL INTEGRATION (CMMI)

ALESSANDRO PEREIRA DOS REIS PAULO CESAR CASTRO DE ALMEIDA ENGENHARIA DE SOFTWARE - CAPABILITY MATURITY MODEL INTEGRATION (CMMI) ALESSANDRO PEREIRA DOS REIS PAULO CESAR CASTRO DE ALMEIDA ENGENHARIA DE SOFTWARE - CAPABILITY MATURITY MODEL INTEGRATION (CMMI) APARECIDA DE GOIÂNIA 2014 LISTA DE TABELAS Tabela 1 Áreas de processo por

Leia mais

Gerenciamento de Projetos de TI. Alércio Bressano, MBA

Gerenciamento de Projetos de TI. Alércio Bressano, MBA Gerenciamento de Projetos de TI Alércio Bressano, MBA Os projetos possuem em seu código genético o fracasso! Eles nasceram para dar errado! Nós é que temos a responsabilidade de conduzí-los ao sucesso!

Leia mais

MODELO SPICE Software Improvement and Capacibilty Determination Avalia o software com foco na melhoria de seus processos (identifica pontos fracos e

MODELO SPICE Software Improvement and Capacibilty Determination Avalia o software com foco na melhoria de seus processos (identifica pontos fracos e MODELO SPICE Software Improvement and Capacibilty Determination Avalia o software com foco na melhoria de seus processos (identifica pontos fracos e fortes, que serão utilizados para a criação de um plano

Leia mais

Qualidade de. Software. Definições. Qualidade do Produto ISO 9126. Processo de. Software. Modelo de Processo de. Software CMM SPICE ISO 12207

Qualidade de. Software. Definições. Qualidade do Produto ISO 9126. Processo de. Software. Modelo de Processo de. Software CMM SPICE ISO 12207 Qualidade de : Visão Geral ISO 12207: Estrutura s Fundamentais Aquisição Fornecimento s de Apoio Documentação Garantia de Qualidade Operação Desenvolvimento Manutenção Verificação Validação Revisão Conjunta

Leia mais

Introdução. AULA 2 A Organização empresarial e a gestão de projetos. Tema relevante em diversas áreas

Introdução. AULA 2 A Organização empresarial e a gestão de projetos. Tema relevante em diversas áreas Universidade do Sagrado Coração Introdução a Gestão de Projetos Paulo Cesar Chagas Rodrigues AULA 2 A Organização empresarial e a gestão de projetos Iniciação 30/set/2008 Engenharia de Produto 2 2 Introdução

Leia mais

IV Seminário Internacional. Maturidade em Gerenciamento de Projetos. Como Medir o Nível de Maturidade em GP de uma Empresa

IV Seminário Internacional. Maturidade em Gerenciamento de Projetos. Como Medir o Nível de Maturidade em GP de uma Empresa IV Seminário Internacional Maturidade em Gerenciamento de Projetos Como Medir o Nível de Maturidade em GP de uma Empresa Palestrante: Leon Herszon F.,MSc, PMP Leon Herszon F., MSc, PMP Diretor Executivo

Leia mais

4. PMBOK - Project Management Body Of Knowledge

4. PMBOK - Project Management Body Of Knowledge 58 4. PMBOK - Project Management Body Of Knowledge No Brasil, as metodologias mais difundidas são, além do QL, o método Zopp, o Marco Lógico do Banco Interamericano de Desenvolvimento (BID) e o Mapp da

Leia mais

GOVERNANÇA DE TI PMBoK (Project Management Body of Knowledge)

GOVERNANÇA DE TI PMBoK (Project Management Body of Knowledge) GOVERNANÇA DE TI PMBoK (Project Management Body of Knowledge) Governança de TI AULA 08 2011-1sem Governança de TI 1 Introdução ao Gerenciamento de Projetos HISTÓRIA PMI Project Management Institute: Associação

Leia mais