UNIVERSIDADE FEDERAL FLUMINENSE LABCEO MBA GERENCIAMENTO DE PROJETOS DÉBORA ATHAYDE HERKENHOFF

Transcrição

1 UNIVERSIDADE FEDERAL FLUMINENSE LABCEO MBA GERENCIAMENTO DE PROJETOS DÉBORA ATHAYDE HERKENHOFF ANÁLISE COMPARATIVA DOS MODELOS DE MATURIDADE DE PROJETOS: OPM3, CMMI, KERZNER E MMGP-PRADO Niterói - RJ 2010

2 DÉBORA ATHAYDE HERKENHOFF ANÁLISE COMPARATIVA DOS MODELOS DE MATURIDADE DE PROJETOS: OPM3, CMMI, KERZNER E MMGP-PRADO Projeto Final apresentado ao curso de MBA em Gerenciamento de Projetos da Universidade Federal Fluminense como requisito parcial para obtenção do Grau de Especialista em Gerenciamento de projetos. Orientador: Prof. Dr. Gilson Brito Alves Lima Niterói RJ 2010

3 DÉBORA ATHAYDE HERKENHOFF ANÁLISE COMPARATIVA DOS MODELOS DE MATURIDADE DE PROJETOS: OPM3, CMMI, KERZNER E MMGP-PRADO Projeto Final apresentado ao curso de MBA em Gerenciamento de Projetos da Universidade Federal Fluminense como requisito parcial para obtenção do Grau de Especialista em Gerenciamento de projetos. Aprovada em 21 de junho de BANCA EXAMINADORA Prof. Dr. Gilson Brito Alves Lima Orientador Universidade Federal Fluminense Prof. Dr. Moacyr Amaral Domingues Figueiredo Co-Orientador Universidade Federal Fluminense Prof. Msc.Níssia Rosa Bergiante Universidade Federal Fluminense Prof. Msc.Nelson Cabral Carvalho Universidade Federal Fluminense Niterói RJ 2010

4 AGRADECIMENTOS A Deus, obrigada por tudo! Obrigada pela minha vida, pela minha saúde, pela minha inteligência, pela minha família, pelos meus amigos, pelos meus estudos, pelo meu trabalho. Obrigada por estar sempre ao meu lado. Aos meus pais, Antonio e Christiane, por toda educação, amor incondicional e carinho, que foram fundamentais para minha formação. Obrigada por serem para mim exemplo de dignidade, valores, inteligência, competência, respeito e determinação. À minha Irmã, Paula, pelo amor, carinho e amizade de todos os dias. Ao meu namorado, Felipe, por todo amor, apoio e compreensão nesse período. À minha família de Niterói, obrigada por me acolherem em sua casa com muito carinho para que eu pudesse concluir mais essa etapa em minha vida. Ao Professor e Orientador Gilson Brito Alves de Lima por todas as oportunidades, todo conhecimento e experiência compartilhada. Ao Professor José Rodrigues Farias Filho, pela oportunidade e ensinamentos. Ao Professor Moacyr Amaral Figueiredo por todo trabalho realizado juntos e que contribuiu para essa monografia. À minha amiga Níssia, por sua paciência, amizade e orientações, além de ser uma companhia maravilhosa em meu dia-a-dia de trabalho. Aos queridos amigos do CIP, pela companhia, apoio e aprendizado. Aos amigos e professores do MBA em Gerenciamento de Projetos. E a todos que direta ou indiretamente contribuíram para que este trabalho fosse realizado.

5 SUMÁRIO 1 INTRODUÇÃO Considerações iniciais Definição da situação problema Objetivos Objetivo Geral Objetivos Específicos Importância do estudo Questões Delimitações do estudo Organização do estudo GERENCIAMENTO DE PROJETOS Conceitos e definições As áreas de conhecimento do gerenciamento de projetos Processos dos projetos Sucesso de projeto MATURIDADE EM GERENCIAMENTO DE PROJETOS Modelos de maturidade Modelo do CMMI (Capability Maturity Model Integration) Críticas ao modelo CMMI Modelo OPM3 (Organizational Project Management Maturity Model) Críticas ao modelo OPM Modelo PMMM (Project Management Maturity Model) Críticas ao modelo Kerzner Modelo Prado-MMGP (Modelo de Maturidade em Gerenciamento de Projetos) Críticas ao modelo MMGP METODOLOGIA Metodologia Delineamento da metodologia Estrutura de comparação proposta ANÁLISE COMPARATIVA ENTRE OS MODELOS Análise comparativa dos níveis de maturidade Análise crítica do estudo CONCLUSÃO Considerações finais Discussão sobre a questão da pesquisa Sugestões de trabalhos futuros REFERÊNCIAS... 91

6 LISTA DE FIGURAS Figura 1: Qual a relação entre a utilização de uma metodologia de GP e o sucesso em projeto? Figura 2: Qual a relação entre o nível de maturidade da organização e a frequência de sucesso em projetos? Figura 3: Organizações imaturas versus organizações maduras Figura 4: Nível de Utilização de Modelos de Maturidade em Gerenciamento de Projetos Figura 5: Modelos de Maturidade em Gerenciamento de Projetos mais utilizados Figura 6: Histórico do nível de utilização dos modelos de Maturidade em Gerenciamento de Projetos Figura 7 : Nível de Maturidade das Organizações Figura 8: Iniciativas que as Organizações pretendem desenvolver nos próximos 12 meses Figura 11:Áreas de processos por categoria e seus níveis de maturidade Figura 12: Representação Estagiada do CMMI Figura 13: Representação Contínua do CMMI Figura 14: Conjunto de elementos do OPM Figura 15: Ciclo de vida do OPM Figura 16: Modelo de maturidade do opm Figura 17: Níveis de maturidade do PMMM Figura 18: Fases do ciclo de vida do modelo de maturidade PMMM Figura 19: Fatores críticos para o Gerenciamento de Projetos e o ciclo de vida do PMMM Figura 20: Níveis de desenvolvimento para alcance da plena maturidade em gestão de projetos Figura 21: Níveis do modelo MMGP Figura 22: Características dos níveis do modelo MMGP Figura 23: Resumo das características dos níveis do modelo MMGP Figura 24: Características dos níveis do modelo de maturidade Prado-MMGP Figura 25: Exemplo de percentual de aderência Figura 26: Delineamento da metodologia... 74

7 LISTA DE TABELAS Tabela 1: Evolução dos índices de status do CMMI Tabela 2: Matriz de critérios do modelo CMMI Tabela 3: Vantagem da representação contínua e da representação estagiada do CMMI Tabela 4: Componentes do opm Tabela 5: Características dos estágios do opm Tabela 6: Características do modelo PMMM Tabela 7 :Dimensões e níveis do modelo do MMGP Tabela 8: Nomenclatura dos níveis Tabela 9: Matriz de comparação Tabela 10: Nomenclatura dos níveis preenchida Tabela 11: Estrutura comparativa Nível Tabela 12: Estrutura comparativa Nível Tabela 13: Estrutura comparativa Nível Tabela 14: Estrutura comparativa Nível Tabela 15: Estrutura comparativa Nível Tabela 16: Correspondência entre níveis de modelos de maturidade Tabela 17: Proposta inicial de níveis de maturidade... 85

8 RESUMO Diante da complexidade do mercado competitivo atual, as empresas têm se voltado para o gerenciamento de projetos como meio de garantir a sua sustentabilidade por meio de resultados mais eficientes e consistentes. Entretanto, para que esta seja capaz de avaliar e se preparar para um posicionamento mais eficiente e sustentável, é preciso que utilize ferramentas que garantam a execução de boas práticas gerenciais de forma padronizada e sistematizada. A pesquisa é realizada no âmbito da avaliação de maturidade do gerenciamento de projetos, que é uma ferramenta que auxilia organizações na avaliação de seus processos, propondo o desenvolvimento de práticas adequadas a metodologias estruturadas de gerenciamento de projetos. A dificuldade em se identificar pontos fortes e fracos de modelos atualmente disponíveis, a fim de utilizar um modelo consiste e adequado a realidade organizacional, incentivou a realização deste estudo, que poderá servir de base para empresas e profissionais que buscam avaliar a gestão de projetos, visto que se realizou uma análise comparativa dos principais modelos de avaliação de maturidade de projetos existentes. Como opção metodológica utilizou-se uma pesquisa bibliográfica suportada por uma análise exploratória a partir da proposição de uma matriz comparativa dos níveis de maturidade dos modelos de maturidade de projetos: CMMI, MMGP, KERZNER e OPM3. Observou-se a diferença entre os critérios utilizados por cada modelo na avaliação e concluiu-se a importância da utilização da avaliação da maturidade e do cuidado na seleção do modelo de acordo com as necessidades da empresa para que a empresa alcance melhores resultados em seus projetos. A pesquisa por fim, apresenta uma proposta de níveis de maturidade para um possível modelo, utilizando-se de um agrupamento dos principais critérios utilizados pelos modelos aqui analisados. Palavras-chave: gerenciamento de projetos, avaliação de maturidade, modelos de maturidade e critérios.

9 ABSTRACT Given the complexity of today's competitive market, companies have turned to project management as a means of ensuring their sustainability through more efficient and consistent results. However, for this to be able to evaluate and prepare for a placement more efficient and sustainable, we must use tools that ensure the implementation of best management practices in a standardized and systematic. The search is performed for the evaluation of maturity of project management, which is a tool that assists organizations in evaluating their processes, proposing the development of best practice methodologies for structured project management. The difficulty in identifying strengths and weaknesses of models currently available, to use a model is appropriate and the organizational reality, encouraged this study, which could provide a basis for businesses and professionals seeking to assess the management of projects, since it held a comparative analysis of the main models for evaluating the maturity of existing projects. As a methodological option, it was used a literature search supported by an exploratory analysis from the proposition of an array of comparative maturity levels of project maturity models: CMMI, PMMM, KERZNER and OPM3. It was observed the difference between the criteria used by each model in the evaluation and concluded the importance of using the maturity evaluation and care in selecting the model according to business needs for the company achieve better results in their projects. The study finally presents a propose of level of maturity for a possible model, using a grouping of the main criteria used by the models reviewed here. Keywords: project management, maturity assessment, maturity models and criteria.

10 10 1 INTRODUÇÃO 1.1 Considerações iniciais No contexto de competitividade atual, e contínua busca por lucratividade e sustentabilidade, são identificadas diversas formas para alcançar esses objetivos da organização, seja através de redução de custos, produtividade, inovação, melhoria de gestão entre outros. A constante mudança dos cenários econômicos apresenta inúmeras oportunidades para as organizações, porém também trazem diversos desafios. A partir dos anos 80, uma revolução vem ocorrendo na introdução e desenvolvimento de novas estruturas organizacionais. Os executivos perceberam que as organizações devem ser mais dinâmicas, ou seja, elas devem ser capazes de se reestruturar rapidamente conforme as necessidades do mercado (Kerzner, 2001). A gestão de projetos vem se tornando elemento fundamental no cenário de globalização, já que o sucesso dos projetos se tornou ainda mais vital para o desempenho dos negócios. Consequentemente as práticas de gerenciamento de projetos vem se desenvolvendo e sendo consolidadas principalmente a partir dos anos 80. Para obter vantagem competitiva a empresa deve ter uma gestão muito eficiente de seus negócios, e conseqüentemente de seus projetos. Explorar ao máximo as oportunidades identificadas e minimizar as ameaças existentes é fundamental, e pode ser sustentada pela utilização de benchmarking através da identificação das melhores práticas do mercado. Segundo Kerzner (2006) as melhores práticas são atividades ou processos reutilizáveis que continuamente agregam valor ao produto final dos projetos. Atualmente, uma das formas utilizadas para avaliar as boas práticas e o desempenho dos projetos, é a avaliação de maturidade, que também permite a comparação entre áreas, empresas ou entre o segmento do mercado em que se está inserido. Harrington (1993) afirma que se não for possível medir, não se pode controlar; se não controlar, não se pode gerenciar; se não gerenciar, não se pode melhorar. A

11 11 partir disso se observa a importância de sistemas de medição para a melhoria da gestão e conseqüentemente alcance de resultados esperados. Os modelos de maturidade de gestão de projetos avaliam o nível atual em que a organização se encontra em relação a determinadas boas práticas préestabelecidas, assim, a partir da análise do estado de em que a organização se encontra, podem ser tomadas providências e desenvolvidos planos de ação para que seja alcançado o pleno desenvolvimento, ou seja, a excelência na gestão. Apesar do conhecimento de importância da gestão, as diretrizes para o gerenciamento de projetos foram alavancadas apenas na última década quando o Project Management Institute (PMI) estabeleceu um programa para criar uma norma internacional para avaliar e desenvolver a habilidade das organizações para atingirem suas estratégias organizacionais através de projetos, o OPM Definição da situação problema Com o crescente interesse na gestão dos projetos, principalmente a partir dos anos 90, vários modelos de maturidade apropriados para gestão de projetos foram sendo desenvolvidos e aperfeiçoados no mercado. Apesar do interesse pelo tema e aumento de pesquisas e estudos nessa área, observa-se que não há modelo com aceitação geral pelas empresas, dificultando dessa forma a comparação de práticas de gestão entre empresas, isto é, a realização de benchmarking. A escolha por um modelo de maturidade em gestão de projetos eficiente pode contribuir para o desempenho organizacional e evolução de suas práticas alcançando resultados mais satisfatórios. Entretanto muitas organizações ainda não utilizam a ferramenta para avaliação de maturidade mais adequada ao seu negócio. Os modelos de maturidade existentes são distintos e não buscam através da padronização das competências de gerenciamento de projetos avaliarem o desenvolvimento da metodologia utilizada na organização, além disso, esses modelos são genéricos demais, e não se adéquam a peculiaridades do setor ou organização avaliada. Isso aumenta a dificuldade da organização utilizar um modelo existente e contribui para criação de modelos adaptados e apropriados a realidade da organização. E isso vai se tornando crítico na medida em que dificulta a comparação padronizada entre empresas ou entre setores.

12 12 Outro exemplo seria quando uma empresa realiza constantes melhorias, fica difícil identificar o quanto essas melhorias são relacionadas ao aumento de maturidade na gestão ou a outros fatores, portanto um modelo de avaliação de maturidade seria importante para esse tipo de avaliação. Um fator problemático para organização que já utiliza avaliação de maturidade através de modelos é a diferença entre conteúdo e abordagem dos modelos existentes, o que tem limitado a habilidade e sucesso de muitas organizações, já que utilização de modelos inadequados ou ineficientes onera tempo e custo. A comparação entre os principais modelos existentes possibilita a análise dos pontos fortes e fracos dos modelos e com isso a análise do modelo de maturidade mais adequado e, portanto mais eficiente para a organização. Conforme apresentado anteriormente dentro da discussão clássica dos modelos de maturidade de gerenciamento de projetos, verifica-se uma lacuna na discussão dos parâmetros de avaliação nos modelos. Muitas organizações ainda se dividem, e não há um consenso em qual o modelo mais completo e eficiente para avaliar a maturidade. Com isso, encontra-se um problema motivante para essa pesquisa: a inexistência de uma análise comparativa estruturada e consistente dos principais modelos de maturidade de gestão de projetos, com intuito de facilitar a compreensão e análise dos modelos existentes a fim de auxiliar na escolha do modelo mais adequado para a realidade atual. 1.3 Objetivos Objetivo Geral Dada a situação problema apresentada, a realização dessa pesquisa buscase identificar os principais modelos de maturidade de gerenciamento de projetos utilizados, e realizar uma análise desses modelos, identificando pontos fortes e fracos. Portanto, o trabalho tem como objetivo principal realizar uma análise comparativa entre os modelos de maturidade mais utilizados em gerenciamento de projetos.

13 Objetivos Específicos Outros objetivos foram essenciais para o completo desenvolvimento do trabalho e alcance do objetivo principal, foram eles: Realizar uma pesquisa bibliográfica nos principais periódicos para levantar os principais aspectos inerentes ao contexto dos modelos de maturidade que permitirão a estruturação da análise comparativa; Apresentar uma revisão bibliográfica dos principais conceitos de gerenciamento de projetos, incluindo as nove áreas de conhecimento de gerenciamento de projetos e seus processos propostos pelo PMBOK; Discutir a importância da avaliação de maturidade e realizar uma ampla pesquisa bibliográfica dos modelos de maturidade de projetos: CMM, OPM3, PMMM e MMGP. 1.4 Importância do estudo A pesquisa por um lado, trará contribuições para o debate atual acerca da gestão de projetos e sua respectiva maturidade, às voltas com enorme proliferação de ferramentas, metodologias e sistemas de gestão, e, por outro lado, poderá fornecer às empresas que aplicam ou pretendem aplicar essa gestão, elementos para repensarem sua gestão de projetos, adequando-se a padrões de boas práticas mais eficientes para conquistarem vantagem competitiva sustentável. Isto será possível através da revisão bibliográfica que apresenta as características de cada modelo pesquisado. Outro fato que salienta a importância da pesquisa é que não há um consenso em relação à utilização de modelos de maturidade. E os modelos já existentes utilizados apresentam várias interpretações e sua utilização não é apropriada e empregado de maneira clara e objetiva. Portanto objetiva-se facilitar a compreensão do assunto, através de uma ampla pesquisa bibliográfica, oferecendo alternativas e comparações entre modelos utilizados para que as empresas consigam identificar o procedimento mais adequado para os seus processos. Com o crescimento do interesse na gestão de projetos e a necessidade de uma organização avaliar sua maturidade em relação a essa gestão, observa-se a

14 14 importância da pesquisa de acordo com os seguintes aspectos: (1) A atual situação de crise mundial requer melhoria de resultados através da redução de custos e melhoria de produtividade; (2) A crescente utilização da gestão de projetos pelas organizações; (3) A necessidade de mensurar adequadamente o nível de maturidade da gestão de projetos a fim de realizar um plano para alcance de níveis mais estruturados; e (4) A necessidade de modelos eficientes e consistentes para medição da maturidade da gestão por processo contemplando parâmetros realmente importantes. 1.5 Questões Nesse aspecto para facilitar o atendimento aos objetivos propostos buscou-se o estabelecimento de quatro questões-chave para o norteamento da pesquisa: 1. Porque utilizar avaliação de maturidade em gerenciamento de projetos? 2. Quais são os principais modelos de maturidade de gerenciamento de projetos? 3. Quais as características de cada modelo? 4. Quais os pontos fracos e fortes de cada modelo? 5. Qual a relação entre os níveis de maturidade de cada modelo? 1.6 Delimitações do estudo Considerando a complexidade de amplitude que envolve a discussão do tema em questão e dada às restrições de tempo e acesso as informações, o presente estudo está limitado à comparação proposta no objetivo, isto é, aos níveis dos quatro modelos de maturidade mais utilizados pelas empresas brasileiras de acordo com a versão preliminar da pesquisa de Benchmarking em gerenciamento de projetos realizada em 2009 pelo PMI. Além disso, não se investigará outros aspectos da gestão, que serão apresentados apenas para se definir o contexto onde se encontra o processo avaliação de maturidade.

15 15 Outro fator limitante do estudo é o prazo de entrega do trabalho, portanto não serão realizadas pesquisas de campo com opinião de profissionais da área, a fim de validar as conclusões obtidas através da pesquisa bibliográfica e da análise crítica dos modelos de maturidade. 1.7 Organização do estudo O trabalho está organizado em cinco capítulos. O primeiro capítulo apresenta as características do estudo. O segundo e terceiro capítulo apresentam um revisão bibliográfica dos temas de gerenciamento de projetos e maturidade respectivamente. No quarto capítulo é apresentada a metodologia do trabalho. No quinto capítulo é realizada uma análise comparativa entre os modelos escolhidos e apresentada uma análise crítica. E por fim, no sexto capítulo é apresentada uma conclusão do trabalho, a discussão das questões da pesquisa proposta e sugestão de trabalhos futuros.

16 16 2 GERENCIAMENTO DE PROJETOS Neste capítulo serão apresentados os principais conceitos e teorias inerentes ao gerenciamento de projetos que serão fundamentais para o desenvolvimento do trabalho proposto e análise dos modelos de maturidade. 2.1 Conceitos e definições É muito importante entender a definição de projeto antes de saber o que é e como gerenciar projetos. O PMI (2008) define projeto como um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo. Essa definição também é apresentada por Vargas (2005) que afirma que um projeto é um empreendimento não repetitivo, caracterizado por uma lógica de eventos, com início, meio e fim, com um objetivo claro e definido, sendo conduzido por pessoas dentro de parâmetros pré-definido de tempo, custo, recursos e qualidade. Outra definição muito similar é proposta por Kerzner (2006) que define projeto como um empreendimento com objetivo bem definido, que consome recursos e opera sob pressões de prazos, custos e qualidade. A partir dessas definições, entende-se a dificuldade de gerenciar um projeto, por se tratar de um conjunto de atividades que envolvem uma complexidade de parâmetros que devem ser gerenciados através de uma abordagem individualista, além de visão holística. A complexidade de um projeto pode ser confirmada já que este é classificado como único, e isto implica na dificuldade do gerenciamento de algo novo, que ainda não foi feito por outras pessoas. Outra dificuldade oriunda da definição de projeto está relacionada ao tempo previsto para a conclusão do projeto, que possui início, meio e fim determinado e uma sequência lógica de eventos, que implica em execução e controle bem precisos. Segundo Vargas (2005) o gerenciamento de projetos é um conjunto de ferramentas que permite que a empresa desenvolva habilidades, inclusive conhecimentos e habilidades individuais, destinados a controle de eventos não

17 17 repetitivos, únicos e complexos, dentro de um cenário de tempo, custo e qualidade pré-determinados. Para Kerzner (2006) a gestão de projetos pode ser definida como o planejamento, a programação e o controle de uma série de tarefas integradas de forma a atingir seus objetivos com êxito, para benefício dos participantes do projeto. O PMI (2008) define o gerenciamento de projetos como a aplicação de conhecimentos, habilidades, ferramentas e técnicas ás atividades do projeto a fim de atender aos seus requisitos. A partir do desenvolvimento dos projetos e aumento de empresas que se organizam por projetos foi sendo intensificada a importância de um conjunto de boas práticas, ou normas a fim de aumentar a qualidade e sucesso do projeto. Com isso o PMI, que é uma organização de profissionais de gerenciamento de projetos estabeleceu um conjunto de diretrizes para o gerenciamento de projetos, através da divulgação do PMBOK A Guide to the Project Management Body of Knowledge, que é um guia reconhecido para profissionais de gerenciamento de projetos. 2.2 As áreas de conhecimento do gerenciamento de projetos As áreas do gerenciamento de projetos descrevem o gerenciamento de projetos em termos de seus processos componentes. Esses processos podem ser organizados em nove grupos integrados (VARGAS, 2005). Cada um desses processos tem um detalhamento específico e uma abrangência própria, porém está integrado, a todo o momento, com os demais, formando um todo único e organizado (VARGAS, 2005). As nove áreas de conhecimento do gerenciamento de projetos são: 1. Gerenciamento da integração área que engloba os processos requeridos para assegurar que todos os elementos do projeto sejam adequadamente coordenados e integrados, garantindo que seu todo seja bem beneficiado. 2. Gerenciamento de escopo área que engloba os processos necessários para assegurar que, no projeto, esteja incluído todo o trabalho requerido, e somente o trabalho requerido, para concluí-lo de maneira bem sucedida.

18 18 3. Gerenciamento de tempo área que engloba os processos necessários para assegurar a conclusão do projeto no prazo previsto. É uma das áreas mais visíveis no gerenciamento de projetos. 4. Gerenciamento de custos área que engloba os processos requeridos para assegurar que um projeto seja concluído de acordo com seu orçamento previsto. 5. Gerenciamento de qualidade área que engloba os processos requeridos para assegurar que os produtos ou serviços do projeto irão estar em conformidade com o solicitado pelo cliente, ou contratante. 6. Gerenciamento de recursos humanos área que engloba os processos necessários para fazer uso mais efetivo do pessoal envolvido com o projeto. 7. Gerenciamento das comunicações área que engloba os processos requeridos para assegurar que as informações do projeto sejam adequadamente obtidas e disseminadas. 8. Gerenciamento de riscos área que visa planejar, identificar, qualificar, quantificar, responder e monitorar os riscos do projeto. 9. Gerenciamento de aquisições área que engloba os processos requeridos para adquirir bens e serviços de fora da organização promotora. Também conhecido como gerenciamento de suprimentos ou contratos. A importância das nove áreas se dá na medida em que o processo de gerenciamento de projetos das empresas requer o aprimoramento nas nove áreas de conhecimento propostas pelo PMI (CARVALHO, 2005). 2.3 Processos dos projetos Um processo é definido pelo PMI (2008) como um conjunto de ações e atividades inter-relacionadas, que são executadas para alcançar um produto, resultado ou serviço pré-definido. Além disso, cada processo possui entradas, ferramentas e técnicas que podem ser aplicadas e saídas. Considerando a metodologia de gerenciamento de projetos, o PMI (2008) o gerenciamento de projetos é realizado através de aplicação e integração apropriada de 42 processos agrupados em cinco grupos:

19 19 Processos de iniciação: Processos realizados para definir um novo projeto ou uma nova fase de um projeto existentes através da obtenção de autorização para iniciar o projeto ou a fase; Processos de planejamento: Processos realizados para definir o escopo do projeto, refinar os objetivos e desenvolver o curso de ação necessário para alcançar os objetivos para os quais os projetos foram criados; Processos de execução: Processos realizados para executar o trabalho definido no plano de gerenciamento do projeto para satisfazer as especificações dos mesmos; Processos de monitoramento e controle: Processos necessários para acompanhar, revisar e regular o progresso e o desempenho do projeto, identificar todas as áreas nas quais serão necessárias mudanças no plano e iniciar as mudanças correspondentes; Processos de encerramento: Processos executados para finalizar todas as atividades de todos os grupos de processos, visando encerrar formalmente o projeto ou a fase. O PMI (2008) afirma que os projetos são compostos de processos. Um processo seria considerado assim como uma série de ações que geram um resultado, além disso, os processos dos projetos são realizados por pessoas, e normalmente se enquadram em uma das duas categorias: Processo do gerenciamento de projetos: garantem o fluxo eficaz do projeto ao longo de sua existência e abrangem as ferramentas e técnicas envolvidas na aplicação de habilidades e capacidades; Processo orientado ao produto: se relacionam com a especificação e a criação do produto do projeto. Os processos orientados ao produto são definidos pelo ciclo de vida do projeto e variam de acordo com a área de aplicação. Harrington (1993) complementa a idéia relacionada a processos, ao envolver no conceito de processos a utilização dos recursos da organização para obtenção dos resultados esperados. Portanto o entendimento dos processos é fundamental para a realização dos projetos e seus produtos e consequentemente melhor desempenho.

20 Sucesso de projeto Para se ter sucesso em projetos, Vargas (2005) afirma que é fundamental entender que um projeto bem-sucedido é aquele que foi realizado conforme o que foi planejado, nem a mais, nem a menos, já que isso indica um mau planejamento. Portanto, afirma que para o sucesso de um projeto é importante que este: -seja concluído dentro do tempo previsto; -seja concluído dentro do orçamento previsto; -tenha utilizado os recursos sem eficientemente e sem desperdícios; -tenha atingido qualidade e desempenho desejadas; -tenha sido concluído com o mínimo possível de alterações no escopo; -tenho sido aceito sem restrições pelo cliente; -tenha sido realizado sem prejuízos ou interrupções nas atividades normais da organização; -não tenha agredido a cultura da organização. Vargas (2005) afirma que o sucesso do projeto está diretamente relacionado com a capacidade que a organização possui em favorecer o ambiente adequado para os projetos. Isso inclui ações do tipo: selecionar corretamente as pessoas-chave do time de projeto; desenvolver um senso de comprometimento na equipe; autoridade suficiente do gerente de projeto para conduzi-lo; respeito e cordialidade com o cliente, fornecedores e outros envolvidos; identificação de processos que necessitam de melhorias; desenvolvimento de estimativas de custos, prazos e qualidade realistas; alternativas de backup em antecedência aos problemas; controle nas modificações; estabelecer prioridade na missão e meta do projeto; otimismo e pessimismo sem exageros; desenvolvimento de linhas de comunicação informal; evitar número excessivo de analises e relatórios e evitar excessiva pressão sobre o time durante períodos críticos. Kerzner (2006) diferencia empresa comum e aquela que obtém excelência em gestão de projetos, pela maneira como as etapas de crescimento e maturidade do ciclo de vida da gestão de projetos são implementadas.

21 21 Segundo Kerzner (2003) a definição de excelência em gerenciamento de projetos pode ser dividida em duas partes. Primeira, é definida como um fluxo contínuo de sucessos em projetos. Porém o autor destaca que o sucesso na implementação de um gerenciamento de projetos não garante que projetos individuais terão sucesso. A segunda parte da definição requer que as decisões de projetos individuais levem em consideração os interesses do projeto e da organização como um todo. Segundo Vargas (2005), uma das grandes vantagens do gerenciamento de projetos é que ele não é restrito, e pode ser empregado em projetos de qualquer complexidade, orçamento, tamanho e em qualquer negócio. Kerzner (2002) classifica os benefícios de uma Metodologia de gestão de projetos como sendo de curto ou longo prazo. Segundo o autor os benefícios de curto prazo têm foco na execução da gestão de projetos e o podem ser descritos como: Diminuição do tempo de ciclo de vida; Redução de custos; Planejamento mais próximo da realidade; Possibilidade de atingir o cronograma; Melhoria na comunicação; Feedback: conhecimento adquirido, lições aprendidas. Segundo o mesmo autor, no longo prazo a existência de uma metodologia de gestão pode trazer os seguintes benefícios: Maior rapidez na entrega, decorrente de controles mais rígidos; Melhor gerenciamento do risco que gera uma tomada de decisão mais qualificada; Aumento da confiança e satisfação do cliente; O provedor auxilia o cliente no planejamento de ações estratégicas; Comparações de desempenho (benchmarking) tornam-se mais fáceis; Um melhor entendimento dos benefícios obtidos a partir do Gerenciamento de Projetos pode ser compreendido a partir da pesquisa realizada pelo PMI em 2008 que confirma a importância de uma metodologia de projetos para o sucesso do projeto apresentando uma relação entre o uso de uma metodologia de

22 22 gerenciamento de projetos e o sucesso dos projetos, conforme apresentado no gráfico a seguir: Figura 1: Qual a relação entre a utilização de uma metodologia de GP e o sucesso em projeto? Fonte: Estudo de benchmarking em gerenciamento de projetos Brasil 2008 PMI As empresas que utilizam uma metodologia de gerenciamento de projetos possuem 76% de sucesso em seus projetos enquanto aquelas que não se orientam com base em uma metodologia estruturada conseguem um índice de apenas 49% de sucesso em seus projetos. Outra questão apresentada pelo estudo do PMI (2008) relaciona o sucesso do projeto com o nível de maturidade da organização, conforme figura a seguir, o que apresenta que na maioria das vezes essa relação tem sucesso:

23 23 Figura 2: Qual a relação entre o nível de maturidade da organização e a frequência de sucesso em projetos? Fonte: Estudo de benchmarking em gerenciamento de projetos Brasil 2008 PMI Com o crescimento do nível de maturidade de uma organização, maior é a frequência de sucesso de seus projetos. Com isso, observa-se a importância da avaliação da maturidade de gestão de projetos para alcançar o sucesso e a excelência nos projetos. Conforme confirmado por Prado (2005) o que motiva o crescimento da maturidade é a esperança de aumento do sucesso na execução de projetos.

24 24 3 MATURIDADE EM GERENCIAMENTO DE PROJETOS Neste capítulo serão apresentados os principais conceitos e teorias inerentes ao gerenciamento de projetos que serão fundamentais para o desenvolvimento do trabalho proposto e análise dos modelos de maturidade. O conceito de maturidade em Gerenciamento de Projetos tem sua raiz no conceito de maturidade de processo, originado no movimento de TQM (Total Quality Management), em que técnicas de controle estatístico da qualidade possibilitaram a redução da variação de resultado dos processos e uma substancial melhoria no desempenho do processo (COOKEDAVIES; ARZYMANOW, 2003 apud KUWAMOTO). Já Kerzner (2002) define a maturidade em gestão de projetos como O desenvolvimento de sistemas e processos que são por natureza repetitivos e garantem uma alta probabilidade de que cada um deles seja um sucesso, destacando, entretanto, que esses sistemas e processos repetitivos apenas aumentam a probabilidade, mas não garantem o sucesso (KERZNER, 2002). Entende-se, portanto, que a maturidade em projetos é a utilização de práticas adequadas para cada organização, e, assim, a avaliação de maturidade de projeto, através de modelos de maturidade avalia a situação atual da organização em relação às práticas existentes e com isso permite que a organização elabore um plano para melhoria de seus processos através de implantação de uma sequência de melhores práticas e conseqüentemente facilita o alcance de níveis mais altos de maturidade. Outro foco para entendimento da maturidade é apresentado por (RABECHINI, 2003) que afirma que a maturidade pode ser considerada um objetivo móvel, visto que seus principais elementos (tecnologia, metodologia e gestão) mudam continuamente em função do mercado, dos negócios e das pessoas. Isto leva a uma percepção de que a maturidade e consequentemente seus modelos devem estar constantemente sendo revistos e atualizados. Não basta apenas alcançar elevados níveis de maturidade, o importante da maturidade é atingir o nível necessário e suficiente que varia de acordo com a necessidade e individualidade de cada organização. Isto se dá, através da obtenção de conhecimento (saber o que), do desenvolvimento das habilidades (saber como) e

25 25 a atitude em alinhá-la com os objetivos do negócio (saber o porquê) (FLEURY e FLEURY, 2000). Portanto o nível de maturidade é inerente a necessidade particular de cada organização. Em relação à caracterização de organizações maduras e imaturas, Carvalho et al (2005) apresenta em seu trabalho a adaptação de um quadro comparativo das características de organizações maduras e imaturas, conforme a seguir: Organizações Imaturas Organizações Maduras Ad hoc, processo improvisado por Coerente com as linhas de ação, o profissionais e gerentes. trabalho é efetivamente concluído. Não é rigorosamente seguido e o Definido, documentado e melhorado cumprimento não é controlado. continuamente. Altamente dependente dos Com o apoio visível da alta profissionais atuais. administração e de outras gerências. Baixa visão do progresso e da Bem-controlada, fidelidade ao qualidade. processo é objetivo de auditoria e de A funcionalidade e a qualidade do controle. produto podem ficar comprometidas São utilizadas medições do produto e para que prazos sejam cumpridos. do processo. Arriscado do ponto de vista do uso de Uso disciplinado de tecnologia. nova tecnologia. Custos de manutenção excessivos. Qualidade difícil de prever. Figura 3: Organizações imaturas versus organizações maduras Fonte: Adaptado de Paulk et al (1995) apud Carvalho et al (2005). O modelo de maturidade em gerenciamento de projetos é essencialmente um arquétipo de crescimento que estabelece estágios pré-definidos, permitindo autoavaliações e aperfeiçoamentos (PRADO, 2003). Torna-se necessário, portanto entender as vantagens e os motivos que levam as organizações a utilizarem modelos de avaliação de maturidade de projetos. Por exemplo, para Kerzner (2002) os principais resultados da aplicação dos modelos de maturidade nas organizações são: descobrir oportunidades para melhoria no gerenciamento de projetos; verificar as mudanças necessárias na organização para a melhoria da maturidade; identificar forças e fraquezas dos projetos; orientar o desenvolvimento de um plano de capacitação. Já Rosemann (2004) apresenta três propósitos principais para a utilização de modelos de maturidade:

26 26 Como uma ferramenta que habilita a descrição do estado atual (As is) avaliando pontos fortes e fracos atuais; Como uma ferramenta que habilite prescrever o desenvolvimento de um roteiro para melhorias; Como ferramenta que habilite a execução de benchmarking para avaliar padrões industriais e outras organizações. Em outras palavras, a avaliação do nível de maturidade possui três principais objetivos, primeiro conhecer a situação atual da organização e consequentemente buscarem alternativas para o aprimoramento de suas práticas, segundo comparar a maturidade entre áreas da organização e por último realizar benchmarking com outras organizações para identificar a situação da empresa em relação a outras do mesmo segmento ou com práticas já estabelecidas. Resumindo, a avaliação da maturidade visa determinar as suas características e desempenhos, nomeadamente os pontos fortes e fracos da situação atual. Esta avaliação e respectivas recomendações vai possibilitar a implementação de um plano de ações para corrigir as anomalias e insuficiências detectadas. A obtenção da maturidade depende de tempo investido em melhorias de seus processos de Gerenciamento de Projetos, e existem dois fatores críticos que podem acelerar o processo de maturidade: O primeiro é a percepção por parte da organização da necessidade de haver gerenciamento de projetos, através da existência de projetos estratégicos, expectativas dos clientes, ganho de competitividade, desenvolvimento de novos produtos, eficiência e efetividade, ou até mesmo assegurar a sobrevivência da organização, e o segundo é o entendimento e comprometimento corporativo em educar e treinar toda a organização, em todos os níveis hierárquicos, em Gerenciamento de Projetos (KERZNER, 1987 apud KUWAMOTO, 2008). Para Cooke-Davies e Arzymanow (2003) apud KUWAMOTO (2008), quanto mais tempo uma indústria sofrer pressões comerciais para obter melhor desempenho, maior a maturidade deste setor. A maturidade do Gerenciamento de Projetos auxilia na compreensão de vários aspectos, entre eles, medir a competência dos profissionais em Gerenciamento de Projetos em escalas generalizadas. Também auxilia na compreensão do ambiente de trabalho dos profissionais e na avaliação da aderência ao negócio para qual o projeto está sendo desenvolvido. A maturidade em gestão de projetos também cria a oportunidade de estudar e compreender a formação de excelentes gerentes de projetos, e pode auxiliar a compreender o mecanismo

27 27 que está por trás deste crescimento profissional. (HARTMAN; SKULMOSKI, 1998 apud KUWAMOTO, 2008). Segundo a versão preliminar do Estudo de benchmarking em gerenciamento de projetos Brasil 2009, realizado pelo PMI e disponível na página do Instituto, com um total de 300 empresas de todo os Brasil participantes, o nível de utilização dos modelos de maturidade no Brasil e os principais modelos utilizados podem ser representados pelos gráficos a seguir: Figura 4: Nível de Utilização de Modelos de Maturidade em Gerenciamento de Projetos Fonte: Estudo de benchmarking em gerenciamento de projetos Brasil 2009 PMI De acordo com o gráfico, metade dos respondentes conhece modelos de maturidade e a outra metade não conhece. Um dado interessante verificado no gráfico está relacionado à porcentagem de 19% de organizações que apesar de conhecerem a avaliação de maturidade não a utilizam. No entanto, o estudo não apresenta as razões dessa não utilização, entretanto é possível presumir seus motivos: falta de qualificação profissional para execução da avaliação, falta de alinhamento com a estratégia organizacional, falta de recursos financeiros, outras priorizações, etc. A seguir são apresentados os modelos de maturidade mais utilizados em gerenciamento de projetos segundo mesma pesquisa de Observa-se que o modelo proposto pelo PMI, o OPM3 é o mais utilizado, com uma percentagem de

28 28 38%, em seguida são utilizados os modelos CMM, MMGP e Kerzner, com 28%, 18% e 9% respectivamente. Figura 5: Modelos de Maturidade em Gerenciamento de Projetos mais utilizados Fonte: Estudo de benchmarking em gerenciamento de projetos Brasil 2009 PMI Abaixo podemos observar o histórico da pesquisa que busca identificar a utilização dos diversos modelos de avaliação de maturidade existentes ao longo dos últimos anos: Nível de Utilização de Modelos de Maturidade em Gerenciamento de Projetos Benchmarking 2007 Benchmarking 2008 Benchmarking 2009 OPM3 39 % 41 % 38 % CMMI 14 % 5 % 28 % Prado 10% 1 % 18 % Kerzner 3 % 47 % 9 % Outros 11 % 4 % - Nenhum 23 % 2 % 26 % Figura 6: Histórico do nível de utilização dos modelos de Maturidade em Gerenciamento de Projetos Fonte: Adaptado do PMI Analisando o histórico de utilização dos modelos de maturidade em gerenciamento de projetos, segundo pesquisa de benchmarking do PMI, observa-se que nos três últimos anos o OPM3 liderou o ranking, enquanto o segundo lugar foi

29 29 ocupado alternadamente pelos modelos CMMI e Kerzner. Embora a utilização do modelo MMGP tenha crescido no último ano, entende-se que este ainda não alcançou uma estabilidade de aceitação no mercado. Ainda segundo a mesma pesquisa pode-se observar o nível de maturidade das organizações respondentes: Figura 7 : Nível de Maturidade das Organizações Fonte: Estudo de benchmarking em gerenciamento de projetos Brasil 2009 PMI

30 30 A partir da análise da figura, observa-se que grande parte das empresas respondentes (77%) estão nos níveis 2 e 3 de maturidade. E apenas 12% dos respondentes estão em níveis avançados de maturidade (4 e 5), o que apresenta um resultado ainda inicial para a grande maioria das empresas em níveis de gerenciamento de projetos. Já a figura a seguir apresenta as principais iniciativas de gerenciamento de projetos que as empresas pretendem desenvolver no próximo ano: Figura 8: Iniciativas que as Organizações pretendem desenvolver nos próximos 12 meses Fonte: Estudo de benchmarking em gerenciamento de projetos Brasil 2009 PMI Através da análise das iniciativas que as organizações pretendem desenvolver no próximo ano, observa-se que 28% das organizações pretendem avaliar a maturidade de seus projetos, confirmando que uma porcentagem alta de empresas está preocupada com essa avaliação e com seus resultados. Ainda ressalta-se um pequeno crescimento em relação a mesma pesquisa do ano anterior, onde 26% das organizações pretendiam investir na avaliação de maturidade. A partir da análise dos gráficos da pesquisa conclui-se a importância dada para as avaliações de maturidade e a necessidade constante das empresas em

31 31 aumentar o nível de maturidade e investir em ferramentas para obter maior sucesso em projetos. 3.1 Modelos de maturidade Os modelos de maturidade são ferramentas que têm por objetivo auxiliar as empresas a alcançar a maturidade no gerenciamento de seus projetos, através da identificação das melhores práticas, realizadas por empresas líderes de mercado (KERZNER, 2002). Apesar da grande variedade de modelos de maturidade existentes atualmente, é importante considerar a afirmação de Hartman e Skulmoski (1998) apud KUWOMOTO (2008) que nenhum modelo de maturidade será completo ou correto, pois a contínua evolução do Gerenciamento de Projetos irá afetar os conceitos dos modelos. Neste trabalho será feita uma abordagem dos principais modelos de maturidade utilizados em gerenciamento de projetos, conforme apresentado anteriormente na pesquisa de Benchmarking 2009, são eles: CMMI, OPM3, KERZNER e o MMGP-Prado. Porém vale salientar a existência e importância de outros modelos de avaliação de maturidade de projetos, que também foram baseados no modelo CMMI, são eles: CBP: Center for business practices; Modelo de Berkeley International Project Framework - ESI Project maturity model (PM2) Interthink PRINCE 2 maturity model CCTA Unified Project management methodology -ILL Modelo do CMMI (Capability Maturity Model Integration) O CMMI é uma abordagem de melhoria de processos que pode ser utilizado para guiar melhoria de processo em projetos, áreas ou organização inteira. Consiste nas melhores práticas direcionadas ao desenvolvimento e à manutenção de

32 32 produtos e dos serviços, abrangendo todo o ciclo de vida do produto, desde sua concepção até a sua entrega e manutenção (CHRISSIS; KONRAD;SHRUM, 2003). Conforme apresentado anteriormente em Estudo de benchmarking em gerenciamento de projetos Brasil 2009 o CMMI é o modelo mais utilizado para gerenciamento de projetos e sua aceitação continua crescendo nos últimos anos, conforme tabela abaixo: Mar/05 Mar/06 Mar/07 Mar/08 Mar/09 Certificações Organizações Companhias participantes Organizações reavaliadas Projetos Organizações não americanas 56,10% 62% 65,50% 68.6% 71,40% Tabela 1: Evolução dos índices de status do CMMI. Fonte: Adaptado pela autora de SEI (2009) apud KUWAMOTO(2008) A criação do modelo teve inicio em 1930, quando Walter Shewahart iniciou seu trabalho em melhoria de processo com os princípios de controle estatístico da qualidade, posteriormente aprimorados por W. Edwards Deming (1986), Philip Crosby (1979) e Joseph Juran (1988). Em 1986 Watts Humphrey e outros se aprofundaram nos conceitos, aplicando-os a software e fornecendo os princípios básicos e conceitos para a construção do CMM. Baseado nos princípios propostos por Humphrey e fortalecido pelo ISCO/IEC, em 1991, o CMM foi criado pelo SEI da Carnegie Mellon University nos EUA, com o objetivo de auxiliar o departamento de defesa americano na escolha de parceiros fornecedores de software (SEI, 2006). Segundo o SEI (2006) com o passar dos anos foram desenvolvidos outros modelos baseados no CMM que procuravam cobrir diferentes áreas de interesse, tais como seleção e compra de software, administração de recursos humanos, desenvolvimento integrado de produto e processo entre outros. Porém a utilização

33 33 de múltiplos modelos desintegrados se tornou problemática para as empresas, na medida em que acarretava maiores despesas de tempo e custo. Com o objetivo de substituir e melhorar os múltiplos modelos de maturidade que surgiram ao longo dos anos, foi desenvolvido o CMMI em substituição ao CMM, combinando três modelos SW-CMM (Capability Maturity Model for Software), SECM (Systemns Engineering Capability Models) e IPD-CMM (Integrated Product Developement Capability Maturity Model), o que suportava características de integração de outras disciplinas específicas do modelo e tinha o objetivo de que todos os produtos desenvolvidos fossem compatíveis com o ISSO/IEC (SEI, 2006). Atualmente o CMMI é formado por três modelos: CMMI for Development v.1.2; CMMI for Acquisition v.1.2 e CMMI for Services (SEI, 2006). O foco desse estudo será o CMMI for development que é um modelo referência para desenvolvimento e manutenção das atividades de produtos e serviços, utilizado por empresas aeroespaciais, bancos, empresas de software, automobilísticas, entre outras (SEI, 2006). A estrutura do modelo CMMI, de acordo com SEI (2006), é composta por: Áreas de processos: Conjunto de práticas relacionadas a uma área que, quando implementadas em conjunto satisfazem um conjunto de metas consideradas importantes para a melhoria daquela área. Existem 22 áreas de processos. Declarações de propósito: É um componente informativo que descreve o propósito da área de processo. Notas introdutórias: necessário descreve o conceito que abrange a área de processo. Área de processo relacionada: É um componente informativo que lista referências relacionadas às áreas de processos e reflete o alto nível de relação entre as áreas de processos. Meta específica: É um componente necessário que descreve requisitos únicos que devem estar presentes para satisfazer a área de processo. Meta genérica: É um componente necessário que descreve os requisitos que devem estar presentes para se institucionalizar a implementação da área de processo.

34 34 Práticas específicas: É um componente esperado de descrição de atividades que são consideradas importantes para alcançar a meta específica associada. Práticas genéricas: É um componente esperado de descrição de atividades necessárias para atingir a meta genérica associada. Sub-práticas: É um componente informativo de descrições detalhadas que fornecem direcionamento para interpretar e implementar uma prática específica ou genérica. A figura a seguir representa os componentes do modelo CMMI e suas interligações: ÁREA DE PROCESSO Declaração de propósito Notas introdutórias Áreas de processo relacionada s Meta específica Meta genérica Prática específica Prática genérica Subpráticas Subpráticas Figura 9: Componentes do Modelo CMMI FONTE: Adaptado do SEI (2006)

35 35 O modelo possui 22 áreas de processo. A figura a seguir apresenta as áreas de processos agrupadas nas quatro categorias e com seus respectivos níveis de maturidade: Figura 11:Áreas de processos por categoria e seus níveis de maturidade Fonte: SEI (2006) A tabela a seguir apresenta um maior detalhamento dos critérios CMMI e suas práticas, ou seja, as 22 áreas de processos subdivididas em práticas específicas:

36 36 Tabela 2: Matriz de critérios do modelo CMMI ÁREAS DE PROCESSOS META PRÁTICA ESPECIFICA CATEGORIA ENGENHARIA Gerência de requisito (NÍVEL 2) O propósito da Gestão de Requisitos (REQM) é gerenciar os requisitos dos produtos e componentes de produto do projeto e identificar inconsistências entre esses requisitos e os planos e produtos de trabalho do projeto. Desenvolvimento de requisitos (NÍVEL 3) O propósito do Desenvolvimento de Requisitos (RD) é produzir e analisar e os requisitos de cliente, de produto e de componente de produto. Solução técnica (NÍVEL 3) O propósito da Solução Técnica (TS) é projetar, desenvolver e implementar soluções para requisitos. Soluções, designs e implementações englobam produtos, componentes de produto e processos de ciclo de vida relacionados ao produto isoladamente ou a combinações de produtos quando apropriado. SG 1 Gerenciar Requisitos SG 1 Desenvolver os Requisitos de Cliente SG 2 Desenvolver Requisitos de Produto SG 3 Analisar e Validar Requisitos SG 1 Selecionar as Soluções de Componentes do Produto SG 2 Elaborar o Design SG 3 Implementar o Design do Produto SP 1.1 Obter um Entendimento dos Requisitos SP 1.2 Obter Comprometimento com os Requisitos SP 1.3 Gerenciar Mudanças de Requisitos SP 1.4 Manter Rastreabilidade Bidirecional dos Requisitos SP 1.5 Identificar Inconsistências entre Trabalho de Projeto e Requisitos SP 1.1 Levantar os Requisitos SP 1.2 Desenvolver os Requisitos de Cliente SP 2.1 Estabelecer os Requisitos de Produto e de Componentes de Produto SP 2.2 Alocar os Requisitos de Componentes de Produto SP 2.3 Identificar os Requisitos de Interface SP 3.1 Estabelecer Conceitos e Cenários Operacionais SP 3.2 Estabelecer uma Definição da Funcionalidade Requerida SP 3.3 Analisar os Requisitos SP 3.4 Analisar os Requisitos Visando Equilíbrio SP 3.5 Validar os Requisitos com Métodos Detalhados SP 1.1 Elaborar as Soluções Alternativas e os Critérios de Seleção SP 1.2 Selecionar as Soluções de Componentes do Produto SP 2.1 Elaborar o Design do Produto ou dos Componentes do Produto SP 2.2 Estabelecer um Pacote de Dados Técnicos SP 2.3 Elaborar o Design das Interfaces Usando os Critérios SP 2.4 Desenvolver, Comprar ou Reusar Análises SP 3.1 Implementar o Design SP 3.2 Elaborar a Documentação de Suporte ao Produto

37 37 Integração de produto (NÍVEL 3) O propósito da Integração de Produto (IP) é montar o produto a partir de componentes de produto, garantir que o produto integrado execute as funções de forma apropriada e entregar o produto. Verificação (NÍVEL 3) O propósito da Verificação (VER) é assegurar que os produtos de trabalho selecionados atendem aos seus requisitos especificados. Validação (NÍVEL 3) O propósito da Validação (VAL) é demonstrar que um produto ou componente de produto atende ao seu uso pretendido quando colocado em seu ambiente alvo. SG 1 Preparar para a Integração de Produto SG 2 Garantir a Compatibilidade das Interfaces SG 3 Montar os Componentes do Produto e Entregar o Produto SG 1 Preparar para a Verificação SG 2 Realizar Revisão por pares SG 3 Verificar os Produtos de Trabalhos Selecionados SG 1 Preparar para a Verificação SG 2 Validar o Produto ou os Componentes de Produto SG 3 Verificar os Produtos de Trabalhos Selecionados SP 1.1 Determinar a Seqüência de Integração SP 1.2 Estabelecer o Ambiente de Integração do Produto SP 1.3 Estabelecer os Procedimentos e Critérios para a Integração do Produto SP 2.1 Revisar as Descrições de Todas as Interfaces SP 2.2 Gerenciar Interfaces SP 3.1 Confirmar se os Componentes do Produto estão Prontos para serem Integrados SP 3.2 Montar os Componentes do Produto SP 3.3 Avaliar os Componentes do Produto Montados SP 3.4 Empacotar e Entregar o Produto ou o Componente de Produto SP 1.1 Selecionar os Produtos de Trabalho para Verificação SP 1.2 Estabelecer o Ambiente de Verificação SP 1.3 Estabelecer Procedimentos e Critérios de Verificação SP 2.1 Preparar para Revisão por Pares SP 2.2 Realizar Revisão por Pares SP 2.3 Analisar Dados de Revisão por Pares SP 3.1 Realizar Verificação SP 3.2 Analisar Resultados de Verificação e Identificar Ações Corretivas SP 1.1 Selecionar os Produtos para Validação SP 1.2 Estabelecer o Ambiente de Validação SP 1.3 Estabelecer Procedimentos e Critérios de Validação SP 2.1 Realizar Validação SP 2.2 Analisar Resultados de Validação CATEGORIA GERENCIAMENTO DE PROJETOS SP 3.1 Realizar Verificação SP 3.2 Analisar Resultados de Verificação e Identificar Ações Corretivas Planejamento de projeto (NÍVEL 2) O propósito do Planejamento do Projeto (PP) é estabelecer e manter planos que definam as atividades de projeto. SG 1 Estabelecer Estimativas SG 2 Elaborar um Plano de Projeto SP 1.1 Estimar o Escopo do Projeto SP 1.2 Estabelecer Estimativas de Atributos de Produtos de Trabalho e Tarefas SP 1.3 Definir Ciclo de Vida do Projeto SP 1.4 Determinar Estimativas de Esforço e Custo SP 2.1 Estabelecer o Orçamento e Cronograma SP 2.2 Identificar Riscos do Projeto SP 2.3 Plano para Gerenciamento de Dados SP 2.4 Plano para Recursos do Projeto SP 2.5 Plano para Conhecimentos e Perfis Necessários SP 2.6 Plano para Envolvimento de stackeholders SP 2.7 Estabelecer o Plano de Projeto

38 38 Monitoramento e controle de projeto (NÍVEL 2) O propósito do Monitoramento e Controle do Projeto (PMC) é proporcionar um entendimento do progresso do projeto, de forma que ações corretivas apropriadas possam ser tomadas quando o desempenho do projeto desviar significativamente do plano. SG 3 Obter Comprometimento com o Plano SG 1 Monitorar o Projeto em Relação ao Plano SG 2 Gerenciar Ações Corretivas até o Encerramento SP 3.1 Revisar Planos que Afetam o Projeto SP 3.2 Conciliar Níveis de Trabalho e Recursos SP 3.3 Obter o Comprometimento com o Plano SP 1.1 Monitorar os Parâmetros de Planejamento do Projeto SP 1.2 Monitorar os Compromissos SP 1.3 Monitorar os Riscos do Projeto SP 1.4 Monitorar o Gerenciamento de Dados SP 1.5 Monitorar o Envolvimento de stackeholders SP 1.6 Conduzir Revisões de Progresso SP 1.7 Conduzir Revisões em Marcos SP 2.1 Analisar Problemas SP 2.2 Tomar Ações Corretivas SP 2.3 Gerenciar as Ações Corretivas Gerência de acordos com fornecedores (NÍVEL 2) O propósito da Gestão de Acordo com Fornecedores (SAM) é gerenciar a aquisição de produtos de fornecedores. Gerência integrada de projeto (NÍVEL 3) O propósito da Gestão Integrada de Projeto (OPD) é estabelecer e gerenciar o projeto e o ambiente dos stackeholders relevantes de acordo com um processo integrado e definido que é adaptado a partir do conjunto de processos padrão da organização. Gerência de riscos (NÍVEL 3) O propósito da Gestão de Risco (RSKM) é identificar potenciais problemas antes que ocorram. Para isso, as SG 1 Estabelecer acordos com o fornecedor SG 2 Satisfazer Acordos com o Fornecedor SG 1 Usar o Processo Definido do Projeto SG 2 Coordenar e Colaborar com os Stackeholders Relevantes SG 1 Preparar para a Gestão de Risco SP 1.1 Determinar o Tipo de Aquisição SP 1.2 Selecionar Fornecedores SP 1.3 Estabelecer Acordos com o Fornecedor SP 2.1 Executar o Acordo com o Fornecedor SP 2.2 Monitorar os Processos Selecionados do Fornecedor SP 2.3 Avaliar os Produtos de Trabalho Selecionados do Fornecedor SP 2.4 Aceitar o Produto Adquirido SP 2.5 Transferir Produtos SP 1.1 Estabelecer o Processo Definido do Projeto SP 1.2 Usar os Ativos de Processo da Organização para Planejar as Atividades do Projeto SP 1.3 Estabelecer o Ambiente de Trabalho do Projeto SP 1.4 Integrar Planos SP 1.5 Gerenciar o Projeto Usando os Planos Integrados SP 1.6 Contribuir com os Ativos de Processo da Organização SP 2.1 Gerenciar o Envolvimento dos Stackeholders Relevantes SP 2.2 Gerenciar Dependências SP 2.3 Solucionar Problemas de Coordenação SP 1.1 Determinar Fontes e Categorias de Risco SP 1.2 Definir Parâmetros de Riscos SP 1.3 Estabelecer uma Estratégia para a Gestão de Risco

39 39 atividades de tratamento de risco podem ser planejadas e colocadas em prática quando necessário, durante a vida do produto ou do projeto, para mitigar impactos indesejáveis na obtenção dos objetivos. SG 2 Identificar e Analisar Riscos SG 3 Mitigar Riscos SP 2.1 Identificar Riscos SP 2.2 Avaliar, Categorizar e Priorizar Riscos SP 3.1 Elaborar Planos de Mitigação de Riscos SP 3.2 Implementar planos de mitigação de riscos Gerenciamento quantitativo de projeto (NÍVEL 4) O propósito da Gestão Quantitativa de Projeto (QPM) é gerenciar quantitativamente o processo definido do projeto para alcançar os objetivos de qualidade e de desempenho de processo estabelecidos do projeto. Foco no processo organizacional (NÍVEL 3) O propósito do Foco no Processo Organizacional (OPF) é planejar, implementar e implantar melhorias do processo organizacional com base na compreensão dos pontos fortes e pontos fracos atuais dos processos e dos ativos de processo da organização. Definição do processo organizacional (NÍVEL 3) O propósito da Definição do Processo Organizacional (OPD) é estabelecer e manter um conjunto de ativos de processo da organização e padrões de ambiente de trabalho disponíveis para uso. SG 1 Gerenciar o Projeto Quantitativamente SG 2 Gerenciar Estatisticamente o Desempenho de Subprocesso SP 1.1 Estabelecer os Objetivos do Projeto SP 1.2 Compor o Processo Definido SP 1.3 Selecionar os Subprocessos que serão Gerenciados Estatisticamente SP 1.4 Gerenciar o Desempenho do Projeto SP 2.1 Selecionar Medidas e Técnicas Analíticas SP 2.2 Aplicar Métodos Estatísticos para Compreender a Variação SP 2.3 Monitorar o Desempenho dos Subprocessos Selecionados SP 2.4 Registrar Dados de Gerenciamento Estatístico CATEGORIA GERENCIAMENTO DE PROCESSOS SG 1 Determinar as Oportunidades de Melhoria de Processo SG 2 Planejar e Implementar as Atividades de Melhoria de Processo SG 3 Implementar os Ativos de Processo da Organização e Incorporar Lições Aprendidas SG 1 Estabelecer Ativos de Processo da Organização SP 1.1 Estabelecer as Necessidades do Processo Organizacional SP 1.2 Avaliar os Processos da Organização SP 1.3 Identificar Melhorias para os Processos da Organização SP 2.1 Estabelecer Planos de Ação de Processos SP 2.2 Implementar Plano de Ação de Processos SP 2.3 Disponibilizar Ativos de Processo da Organização SP 2.4 Incorporar Experiências Relacionadas a Processos aos Ativos de Processo da Organização SP 3.1 Implantar Ativos de Processo da Organização SP 3.2 Implantar Processos Padrão SP 3.3 Monitorar a Implementação SP 3.4 Incorporarar Experiências Relacionadas a Processos nos Ativos de Processo da Organização SP 1.1 Estabelecer Processos Padrão SP 1.2 Estabelecer Descrições de Modelos de Ciclo de Vida SP 1.3 Estabelecer Critérios e Guias para Adaptação SP 1.4 Estabelecer Repositório de Medidas da Organização SP 1.5 Estabelecer Biblioteca de Ativos de Processo da Organização SP 1.6 Estabelecer Padrões de Ambiente de

40 40 Treinamento organizacional (NÍVEL 3) O propósito do Treinamento Organizacional (OT) é desenvolver as habilidades e o conhecimento das pessoas para que elas possam desempenhar seus papéis de forma eficiente e eficaz. SG 1 Estabelecer uma Capacidade de Treinamento Organizacional SG 2 Fornecer Treinamento Necessário Trabalho SP 1.1 Estabelecer Necessidades Estratégicas de Treinamento SP 1.2 Determinar as Necessidades de Treinamento de Responsabilidade da Organização SP 1.3 Estabelecer um Plano Tático de Treinamento Organizacional SP 1.4 Estabelecer Capacidade de Treinamento SP 2.1 Realizar Treinamentos SP 2.2 Estabelecer Registros de Treinamento SP 2.3 Avaliar a Eficiência dos Treinamentos Desempenho do processo organizacional (NÍVEL 4) O propósito do Desempenho do Processo Organizacional (OPP) é estabelecer e manter um entendimento quantitativo do desempenho do conjunto de processos padrão da organização no suporte dos objetivos de qualidade e de desempenho de processo, e prover dados de desempenho de processo, baselines e modelos para gerenciar quantitativamente os projetos de uma organização. Inovação organizacional (NÍVEL 5) O propósito da Inovação Organizacional (OID) é selecionar e implementar melhorias incrementais e inovadoras que melhorem os processos e as tecnologias de uma Organização de forma mensurável. As melhorias dão suporte aos objetivos de qualidade e de desempenho de processo da organização derivados dos objetivos negócio da organização. SG 1 Estabelecer Baselines e Modelos de Desempenho SG 1 Selecionar Melhorias SG 2 Implementar Melhorias CATEGORIA SUPORTE SP 1.1 Selecionar Processos SP 1.2 Estabelecer Medidas de Desempenho de Processo SP 1.3 Estabelecer Objetivos de Qualidade e de Desempenho de Processo SP 1.4 Estabelecer Baselines de Desempenho de Processo SP 1.5 Estabelecer Modelos de Desempenho de Processoo SP 1.1 Coletar e Analisar Propostas de Melhoria SP 1.2 Identificar e Analisar Inovações SP 1.3 Melhorias Piloto SP 1.4 Selecionar Melhorias para Implantação SP 2.1 Planejar a Implantação SP 2.2 Gerenciar a Implantação SP 2.3 Medir os Efeitos de Melhorias Gerência de configuração (NÍVEL 2) O propósito da Gestão de Configuração (CM) é SG 1 Estabelecer Baselines SP 1.1 Identificar Itens de Configurações SP 1.2 Estabelecer um Sistema de Gestão de Configuração SP 1.3 Criar ou Liberar baselines

41 41 estabelecer e manter a integridade dos produtos de trabalho, utilizando identificação de configuração, controle de configuração, balanço de configuração e auditorias de configuração. SG 2 Rastrear e Controlar alterações SG 3 Estabelecer a Integridade SP 2.1 Rastrear Solicitações de Alteração SP 2.2 Controlar itens de Configuração SP 3.1 Estabelecer os Registros de Gestão de Configuração SP 3.2 Executar Auditorias de Configuração Garantia da qualidade de produto e processo (NÍVEL 2) O propósito da Garantia da Qualidade de Processo e Produto (PPQA) é munir a equipe e a gerência com uma visão clara sobre os processos e seus produtos de trabalho associados. SG 1 Avaliar Objetivamente processos e Produtos de Trabalho SG 2 Fornecer um Entendimento Objetivo SP 1.1 Avaliar Objetivamente os Processos SP 1.2 Avaliar Objetivamente Produtos de Trabalho e Serviços SP 2.1 Comunicar e Garantir a Solução de Não-conformidades SP 2.2 Estabelecer Registros Medição e análise (NÍVEL 2) O objetivo da medição e análise (MA) é desenvolver e sustentar a capacidade de medições utilizada para dar suporte às necessidades de gerenciamento de informações. Resolução e análise de decisão (NÍVEL 3) O propósito da Análise de Decisão é analisar decisões possíveis usando um processo de avaliação formal que avalia alternativas identificadas com relação a critérios estabelecidos. Resolução e análise de causa (NÍVEL 5) O propósito da Análise de Causa e Solução de Problemas (CAR) é identificar causas de defeitos e de outros problemas e tomar ações para evitar que ocorram no futuro. SG 1 Alinhar as Atividades de medição e análise SG 1 Fornecer Resultados de Medições SG 1 Avaliar Alternativas SG 1 Determinar Causas de Defeitos SG 2 Tratar as Causas dos Defeitos SP 1.1 Estabelecer Objetivos de Medições SP 1.2 Especificar Medidas SP 1.3 Especificar Procedimentos de Coleta e armazenamento de Dados SP 1.4 Especificar Procedimento de Análises SP 2.1 Coletar Dados de Medições SP 2.2 Analisar Dados de Medições SP 2.3 Armazenar Dados e Resultados SP 2.4 Comunicar Resultados SP 1.1 Estabelecer Guias para Análise de Decisão SP 1.2 Estabelecer Critérios de Avaliação SP 1.3 Identificar Soluções Alternativas SP 1.4 Selecionar Métodos de Avaliação SP 1.5 Avaliar Alternativas SP 1.6 Selecionar Soluções SP 1.1 Selecionar Dados de Defeitos para Análise SP 1.2 Analisar Causas SP 2.1 Implementar Propostas de Ação SP 2.2 Avaliar os Efeitos das Mudanças SP 2.3 Registrar Dados Fonte: (SEI, 2007) A versão 1.2 do CMMI, a mais atual, apresenta duas formas de representação: (1) por estágio, como o CMM tradicional, que é bem conhecida por

42 42 empresas que desejam realizar benchmarking da maturidade de processos e (2) contínua, semelhante a ISSO/IEC 15504, menos conhecida e possui as mesmas áreas de processo arranjadas em grupos mais flexíveis de quatro categorias de áreas de processos. (SEI, 2007). Representação contínua De acordo com o SEI (2006) a representação contínua permite a organização selecionar áreas de processo (ou grupos de áreas de processos) e melhorar os processos relacionados. Essa representação utiliza níveis de capacidade para caracterizar melhorias relativas a uma área de processo individual. Para suportar a utilização da representação contínua, as áreas de processos são organizadas em quatro categorias: gerenciamento de processos, gerenciamento de projetos, engenharia e suporte. Uma vez selecionada a área de processo, devese identificar o quanto se quer amadurecer os processos relacionados àquela área, isto é definir qual nível de capacidade pretende-se alcançar (SEI, 2006). Na representação contínua, segundo Ataides (2006) é possível que sejam selecionados áreas de processo (PA) para implementação dos objetivos de qualidade e maturidade possibilitando assim o cumprimento apenas de objetivos gerais e específicos de cada área de processo definidos para cada nível de maturidade. Observa-se que a representação contínua possui uma abordagem mais flexível e permite que a organização selecione quais áreas de processo deseja enfatizar primeiro, além de direcionar esforços e recursos disponíveis para objetivos menores e centralizados (ATAIDES, 2006). É importante se atentar para as dependências entre algumas áreas de processo, pois se quando se conhece os processos da empresa que necessitam de melhorias e entende-se as dependências entre processos descritas no CMMI, a representação contínua se torna uma boa opção (SEI, 2006). Esta representação é composta por seis níveis de capacidade, do 0 ao 5, conforme apresentado por Kuwamoto (2008): Nível 0 Incompleto: são os processos que ainda não são executados ou são parcialmente executados.

43 43 Nível 1 Dirigido: são os processos que satisfazem as metas específicas estabelecidos para o processo. Nível 2 Gerenciado: são os processos dirigidos (nível 1) que têm uma infra-estrutura básica de suporte: são planejados e executados conforme políticas estabelecidas; empregam pessoal com habilidade para produzir resultados controlados; envolvem os stakeholders relevantes; são monitorados, controlados e revistos; têm sua aderência avaliada em relação ao processo descrito. Nível 3 Definido: são os processos gerenciados, realizados a partir de um guia organizacional para a consecução do processo. As principais diferenças entre os níveis 2 e 3 estão no escopo e rigor dos padrões, descrições de processos e procedimentos, nos quais há uma maior consistência e rigor na descrição dos processos. Nível 4 Gerenciado Quantitativamente: são os processos controlados através de controle estatístico e outras técnicas quantitativas. Nível 5 Otimizado: são os processos quantitativamente gerenciados que são melhorados com base nas variações inerentes ao próprio processo. Representação estagiada Já a representação estagiada, de acordo com o SEI (2006) utiliza um conjunto predefinido de áreas de processos para definir um caminho de melhoria para a organização. Esse caminho é caracterizado por níveis de maturidade e cada nível fornece um conjunto de áreas de processos que caracterizam diferentes comportamentos organizacionais (SEI, 2007). Para Ataídes (2006) na representação por estágio a organização deve alcançar um conjunto de objetivos pré-definidos para todas as áreas de processo estipuladas pelo modelo a fim de alcançar o nível seguinte. Ou seja, o modelo é organizado em áreas de processo que por sua vez são arranjadas em áreas de conhecimento e níveis de maturidade. Atingir um determinado nível de maturidade significa implementar todas as atividades deste nível adicionadas a todas as atividades dos níveis anteriores. A representação por estágios se torna uma boa escolha quando não se sabe onde começar e quais processos devem ser escolhidos para melhoria, pois ela

44 44 fornece um conjunto específico de processos para melhorar em cada estágio (SEI, 2006). Esta representação é composta por cinco níveis de maturidade, que são: Nível 1 - Inicial: O processo de desenvolvimento de software é ad hoc e até mesmo caótico. Poucos processos são definidos e o sucesso depende de esforços individuais; falta planejamento e controle de processos. Nível 2 - Repetível: Processos de gerenciamento de projetos básicos estão estabelecidos para mensurar e controlas custos, prazos e funcionalidades (qualidade). São firmados compromissos e é estabelecido um nível de gerenciamento. Os processos estabelecidos permitem a repetição de sucessos em projetos semelhantes, entretanto o sucesso depende do gerenciamento do projeto. Nível 3 - Definido: O processo de desenvolvimento de software tanto técnico quanto gerencial é documentado, padronizado, e integrado a um processo padrão de desenvolvimento da empresa. Todos os projetos usam uma versão padronizada para o desenvolvimento e manutenção de softwares. Os processos e técnicas gerenciais são bem definidos e permitem a avaliação do processo, com medições de desempenho, realização de auditorias de forma rotineira e testes padrões. Nível 4 - Gerenciada: Mensurações detalhadas do processo de desenvolvimento de software e qualidade dos produtos são coletadas, e o processo é quantitativamente definido, avaliado e controlado. Nível 5 - Otimização: Processo de melhoria continua é estabelecido pela quantidade de feedbacks do processo e do desenvolvimento de inovações e tecnologias. As figuras a seguir ilustram a visão de como as áreas de processos são utilizadas nas duas representações do modelo CMMI:

45 45 Figura 12: Representação Estagiada do CMMI Fonte: Adaptação SEI (2006) Figura 13: Representação Contínua do CMMI Fonte: Adaptação SEI (2006) Algumas informações são importantes quando se opta por utilizar o modelo CMMI (SEI, 2006): -Deve-se selecionar a parte da organização, ou os projetos que serão envolvidos; -Identificar a representação mais adequada aos objetivos da empresa (estagiada ou contínua); -Embora as áreas de processos descrevam as características de uma organização comprometida com a melhoria de processos, a interpretação das áreas de processos deve ser realizada utilizando profundo conhecimento do

46 46 CMMI, da organização, do ambiente de negócio e das circunstâncias específicas envolvidas; -Para interpretar as práticas é importante considerar o contexto na qual essas práticas são utilizadas e determinar como as práticas satisfazem as metas da área de processo no contexto; Dessa forma, a definição da representação do modelo a ser utilizada se mostra como fator importante para o sucesso da iniciativa. A seguir podemos observar uma comparação das vantagens de cada representação que deve ser analisada antes de optar por uma das representações: Representação contínua Garante liberdade para selecionar uma ordem de melhoria que melhor atendas aos objetivos do negócio da organização e mitigue as áreas de riscos. Permite uma visualização do aumento da capacidade alcançada em cada área de processo. Permite a melhoria de diferentes processos em ritmos diferentes. Reflete uma abordagem nova, que ainda não possui dados para demonstrar seu retorno sobre o investimento. Representação estagiada Permite a organização ter um caminho de melhoria predefinido e comprovado. Foca num conjunto de processos que fornece à organização uma capacidade específica que corresponde a um nível de maturidade. Resume os resultados de melhoria de processos em uma forma simples um único nível de maturidade Constrói um histórico relativamente longo que inclui estudos de caso e dados para demonstrar o retorno sobre o investimento. Tabela 3: Vantagem da representação contínua e da representação estagiada do CMMI. Fonte: SEI, 2006 Ainda segundo SEI (2006) existe três fatores que influenciam a decisão de qual representação deve-se utilizar: Fatores de negócio: os processos organizacionais devem suportar os objetivos de negócio; Fatores culturais: a capacidade de a organização desenvolver um programa de melhoria;

47 47 Legado: as experiências anteriores da organização em relação a modelos. É importante ressaltar que, com base em experiências, Ataídes (2006) afirma que a organização possui ganhos maiores quando foca seus esforços de melhoria em um numero controlável de áreas de processo Críticas ao modelo CMMI Apesar de sua ampla difusão, o modelo é considerado burocrático e rígido, exigindo alta concentração, em detrimento a outros aspectos importantes para a organização, e faz com que as empresas evitem aceitar projetos arriscados com o intuito de atingir melhores avaliações (HARTMAN; SKULMOSKI, 1998) apud KUWAMOTO (2008). KUWAMOTO (2008) também apresenta os resultados de uma pesquisa feita por BADDO e HALL (2003) que apontam alguns fatores considerados mais importantes para a não adoção de um SPI (Software Performance Improvement), categoria que também se encaixa o CMMI: Preocupação: Ocorre uma grande preocupação em relação aos recursos para adotar-se um modelo de SPI; Pressões comerciais: As pressões comerciais também são vistas como uma dificuldade para a implantação de um SPI, pois a necessidade da empresa de manter sua posição no mercado, muitas vezes envolve satisfazer o cliente a qualquer custo, fazendo com que num ambiente em que o imperativo comercial é forte, os incentivos para uso de SPI sejam comprometidos. Resistência: Outro ponto importante para não adoção dos SPIs é a resistência dos profissionais, baseada em experiências anteriores ruins, inércia e falta de suporte geral. Evidências: Os pesquisadores encontraram ainda que a falta de evidências de sucesso dos casos de SPI, também é um dos fortes motivos para não adoção de SPI. Esse ponto, particularmente, é compartilhado por diversos outros trabalhos sobre SPIs. Habilidades: a falta de habilidade para utilizar-se de um SPI é outro fator citado, na opinião de gerentes seniores e desenvolvedores é crucial que existam pessoas capacitadas para direcionar os programas de SPI nas organizações. Para

48 48 gerentes de projeto, o alto índice de rotatividade é uma das causas que leva a um grupo inexperiente. Imposição: Refere-se à forma como os SPIs são adotados nas empresas, através de imposição e comunicação inadequada, prejudicando dessa forma todo o processo de adoção por parte dos envolvidos. Segundo KUWAMOTO (2008), os autores Brady e Davies (2004) criticam no modele: a dificuldade na manutenção das capabilities através dos projetos, a dificuldade das empresas em transferir aprendizado de um projeto para outro, e de um projeto para a organização. Para esses autores, existe uma falha na literatura sobre projetos, sobre como uma empresa constrói capabilities ao longo do tempo. A partir de uma pesquisa realizada por Staples et al. (2006) apud KUWAMOTO (2008), os pesquisadores verificaram que os principais motivos para a não adoção do CMMI são: a empresa é muito pequena, os custos são muito altos para implantação, a empresa não tem tempo para aplicar o CMMI e a empresa já utiliza outro processo de SPI. Já Bolinger e McGowan (1991) apud KUWAMOTO (2008) reconhecem o impacto e importância do modelo CMMI para a comunidade de software e ressalta as grandes qualidades do modelo, tais como: a integração de pessoas envolvidas em um projeto em forma de uma equipe de desenvolvimento pró-ativa e coesa; a criação de um fórum aberto para a discussão de padrões de desenvolvimento e engenharia de software, fazendo com que as próprias pessoas apliquem o modelo por, e o levem a sério, e utilizem os bem-concebidos conceitos e métodos de treinamento para as pessoas que realizam as avaliações do processo. Entretanto, para os autores, uma efetiva avaliação de processo vai além de bons métodos de registro e análise de processo, que são utilizados pelo modelo CMMI, envolvendo também um detalhado modelo gráfico do processo de desenvolvimento de software. E por outro lado, Bolinger e McGowan (1991) apud KUWAMOTO (2008) apresentam fortes críticas principalmente sobre os métodos de avaliação do modelo. Para os pesquisadores, os níveis 2 e 3 de maturidade do CMMI fornecem ferramentas que realmente auxiliam na obtenção de melhorias no processo de desenvolvimento de softwares, ao passo que os níveis 4 e 5 carecem de informações substanciais que auxiliem a empresa a atingir o que é proposto pelo

49 49 modelo. Há muitas interpretações sobre o real significado dos níveis 4 e 5 em parte pela falta de clareza sobre suas definições atreladas ao seu questionário de avaliação. O Connell e Saiedian (2000) apud KUWAMOTO (2008), também criticam os resultados dos modelos de avaliação e seleção de fornecedores para o Departamento de Defesa dos Estados Unidos, que é o mesmo processo de certificação para empresas no CMMI, alegando que estes nem sempre correspondem à realidade. Segundo o autor, para empresas maduras, a avaliação é simples, e é de certa forma fácil atingir um nível de maturidade. Entretanto, empresas menos maduras, devem trabalhar muito para conseguir vender sua imagem. O próprio sistema possibilita que estas empresas pareçam ser mais maduras na avaliação, através de quatro estratégias principais: Imprecisão intencional: Os avaliados utilizam-se do pouco tempo e conhecimento limitado dos avaliadores para inflar suas qualificações. Detalhamento intencional: Os avaliados também podem inundar os avaliadores de informações, em termos de quantidade e complexidade, fazendo com que o avaliador não tenha alternativa frente ao seu tempo limitado e assuma que, embora de forma intrincada, o avaliado está de acordo com as normas da certificação. Escolha inapropriada de projetos: A SEI determina que o avaliado deve escolher projetos para a avaliação que represente tipicamente seu processo de implantação de software. Obviamente, o avaliado irá escolher, dentro de seu portfólio, os projetos com o maior grau de maturidade e com as equipes melhores qualificadas para a avaliação. Treinamento da equipe: Os funcionários que participarão das entrevistas de avaliação são treinados para que possam fornecer as melhores respostas possíveis em conformidade para obter a avaliação Modelo OPM3 (Organizational Project Management Maturity Model) O Organizational Project Management Maturity Model (OPM3), modelo de maturidade organizacional para gestão de projetos, elaborado pelo PMI entre 1998 e 2003, com o objetivo de propor um modelo de maturidade genérico, têm como

50 50 missão suportar as organizações a desenvolverem capacidades necessárias a fim de alinhar seus objetivos estratégicos com a sua operação através de projetos (OPM3, 2008). Segundo Prado (2004) o modelo reflete a experiência desta instituição com gerenciamento de projetos e foi desenvolvido num projeto voluntário que envolveu quase 800 consultores de 35 países durante 6 anos. Portanto é um modelo consistente e robusto. O modelo está baseado nas seguintes definições do PMI: Portfólio é uma coleção de projetos e/ou programas e outro trabalho que são agrupados para facilitar o efetivo gerenciamento do trabalho para atingir os objetivos estratégicos Programas é um grupo de projetos inter-relacionados, eventualmente com outras ações do tipo não-projeto, gerenciadas de forma coordenada para obter benefícios e controles não disponíveis caso fossem gerenciados individualmente e visando a um objetivo maior e que devem ser gerenciados de forma coordenada Projeto como já foi discutido anteriormente no capítulo 2, é um esforço levado a efeito para produzir um produto, serviço ou resultado único. O modelo fornece para a organização uma visão do gerenciamento nos três cenários apresentado (programas, portfólio e projetos) a fim de alcançar melhores práticas em cada um desses domínios (OPM3, 2008). Essas melhores práticas do modelo estão alinhadas com os padrões do PMI e podem conduzir a organização a resultados melhores e mais sustentáveis através da execução de sua estratégia (OPM3, 2008). Observa-se um foco evidente do modelo na estratégia organizacional o que o torna um modelo diferenciado. Em relação a estrutura do modelo, esta é formada por componentes principais que estão relacionam ente si, que são: Melhores práticas (Best practice) Capacidades (Capability) Resultados (Outcomes) Tabela 4: Componentes do opm3 Fonte: Adaptado do OPM3 (2008) Conjunto de capacidades organizacionais relacionadas. Representam o critério do OPM3 para avaliação de maturidade organizacional. Indicam a variedade de interdependências com o modelo. Existem duas categorias de melhores práticas:

51 51 1. SMCI (Standardize, measure, control e continuously improve): classificados pelos estágios de maturidade dos domínios do gerenciamento de portfólio, de programa e de projeto. Cada boa prática e capacidade no OPM3 devem ser mapeadas para um ou mais de um desses domínios. A seguir são apresentadas as características de cada estágio: Modelo OPM3 Níveis Padrão Características Desenvolver/adquirir processo comum e fiscalizar o cumprimento. Medida Medir padrões de desempenho e características críticas de processo. Controle Melhoria Contínua Desenvolver, implementar e auditar sistemas para manter a estabilidade dos processos de controle. Identificar problemas de processos e implementar melhoria contínua. Tabela 5: Características dos estágios do opm3 Fonte: Adaptação de OPM3, OE (organizational enablers): capacitadores organizacionais que são estruturais, culturais, tecnológicos e recursos humanos que permeiam a implementação dos SMCI. Esses capacitadores organizacionais sustentam os avanços na maturidade organizacional. Esta categoria de boa prática auxilia a organização alcançar as boas práticas de SMCI (OPM3, 2008). O OPM3 é constituído por um conjunto de 3 elementos interligados: conhecimento, levantamento e plano de melhoria, conforme apresentado na figura abaixo:

52 52 Figura 14: Conjunto de elementos do OPM3 Fonte: OPM3 do PMI, 2008 O elemento conhecimento contém a descrição do modelo e a forma de aplicá-lo, além de explicar a importância do gerenciamento de projetos no nível organizacional e como a maturidade organizacional em gerenciamento de projetos pode ser alcançada. O elemento levantamento apresenta os passos e ferramentas para sua aplicação, ou seja, os procedimentos que permitem uma organização se medir em relação às melhores práticas descritas na dimensão conhecimento. O plano de melhoria é um guia do método que permite planejar e priorizar o desenvolvimento de capacidades e implementação de melhores práticas que levará a organização do estado atual de maturidade a um estado desejado de maturidade. O ciclo de melhoria do OPM3 utiliza os 3 elementos apresentados (conhecimento, levantamento e plano de melhoria) e indica os seguintes passos para sua utilização. Para o elemento de conhecimento, o primeiro passo recomendado é a preparação e o conhecimento do modelo pela equipe que vai utilizá-lo. O elemento levantamento é subdividido em duas etapas: o levantamento de alto nível ou preliminar e o levantamento compreensivo ou de capacidades. O levantamento de alto nível consiste de um questionário com 151 perguntas, com

53 53 respostas do tipo sim ou não utilizado na produção de quatro gráficos que indicam, de forma geral, a maturidade da organização frente ao padrão (ZAGUIR, 2006). O questionário é preenchido utilizando um Sistema informatizado interativo disponível em um CD, o programa avalia as respostas e fornece um resultado em percentual para a uma avaliação geral da organização, por domínios (programas, portfólio e projeto) e por processos (SCMI). O elemento melhoria é subdivido na elaboração de um plano de melhoria com base nas melhores práticas e capacidades identificadas como não desenvolvidas no âmbito do domínio e estágio de maturidade de interesse e na implementação das melhorias que foram estabelecidas no plano. Para finalizar o modelo, recomenda-se a repetição do processo de avaliação, visando sua melhoria contínua. A figura a seguir ilustra os passos para o ciclo de vida do modelo OPM3: Figura 15: Ciclo de vida do OPM3 Fonte: Adaptado do PMI (2008) apud SANTOS A estrutura do OPM3 é concebida em 4 dimensões (ZAGUIR, 2006).: 1ª - A primeira trata o relacionamento de uma melhor prática, 586 disponíveis, com um conjunto de capacidades que necessitam estar desenvolvidas para o que, segundo o padrão, esta melhor prática seja reconhecida como implementada. 2ª- A segunda estabelece o relacionamento entre uma melhor prática e suas capacidades a um domínio, que pode ser o projeto, o programa (conjunto de projetos) ou portfólio (conjunto de todos os programas e projetos da Organização).

54 54 3ª - A terceira dimensão estabelece o relacionamento de uma melhor prática e suas capacidades a um determinado estágio de maturidade de processo: estágio de padronização (standard), medição (measured), controle (controlled) e o estágio da melhoria contínua (improvement). 4ª - A quarta dimensão refere-se à associação de uma capacidade a determinado grupo de processo de gestão, conceito extraído do PMBoK (PMI, 2008), a saber: inicialização (initialization), planejamento (planning), execução (execution), controle (controlling) e encerramento (closing). As dimensões do modelo são ilustradas na figura a seguir: Figura 16: Modelo de maturidade do opm3 Fonte: Adaptado de PMI (2003) apud RUY BOUER A metodologia de avaliação de maturidade do OPM3 permite que a organização foque em um domínio específico (projeto, programa ou portfólio), em um capacitador organizacional ou em um estágio específico (padrão, medido, controle ou melhoria contínua). Essa avaliação ajuda a organização identificar melhores práticas, capacidades ou saídas que devem ser exibidas (OPM3, 2008). Existem vários tipos de avaliação do OPM3 desde auto-avaliação ou avaliação por um assessor do OPM3 certificado. A auto-avaliação foca exclusivamente nos altos níveis de melhores práticas enquanto os outros focam em mais detalhadas capacidades e resultados. Através de um comitê de padrões foram discutidas as principais capacitações inerentes a um gerenciamento de projetos organizacional, são elas (Schlichter (2001) apud Rabechini e Pessoa (2005):