Prévia do material em texto

1 
 
 
 
 
 
 
 
 
 
 
 
 
 
MATURIDADE EM GERENCIAMENTO DE 
PROJETOS 
Parte I 
 
Conteudista 
Prof.ª Dr.ª RENNE MARTINS BARBALHO 
 
 
 
 
2 
 
Introdução 
Este módulo tem como objetivo apresentar os conceitos sobre a 
Maturidade em Gerenciamento de Projetos nas Organizações, como todos tem 
acompanhado, existe hoje uma nova ordem mundial que, cada vez mais, faz 
com que as organizações deixem de usar o modelo tradicional de gestão 
empresarial e passem a utilizar um gerenciamento voltado para projetos. 
Nesse cenário extremamente competitivo, onde a demanda está 
crescendo ano após ano e os recursos estão cada vez mais escassos, as 
organizações conduzem a gestão de forma projetizada (buscando sempre 
melhorar a eficiência e a eficácia de seus processos) e utilizando-se de vários 
novos métodos em busca de seus objetivos estratégicos, para assim 
alcançarem, internamente, um nível de maturidade na gestão de projetos que 
lhes permita um diferencial em relação ao mercado. Vamos pensar em 
maturidade de gerencia de projetos como o grau com que o gerenciamento de 
projetos está sendo aplicado dentro da organização, em todos os níveis. 
Durante anos, as organizações aplicaram conceitos fundamentais para a 
sua sobrevivência como “TQM”, “Engenharia Simultânea”, “Reengenharia” e 
“Benchmarking”, esses modismos foram fundamentais para algumas mudanças 
dentro das organizações, que buscavam sempre benefícios, 
independentemente, da forma de trabalho que cada uma tinha no momento. 
Quanto mais as empresas foram saindo da forma tradicional e processual 
e começaram a caminhar no sentido de trabalhos mais agéis e projetizados, 
houve a percepção de que não bastava, para o sucesso de um projeto, apenas 
a boa vontade de uma equipe quase sempre despreparada e, dificilmente, com 
objetivos e funções claramente definidos, e/ou a contratação de empresas e 
funcionários que “fizessem” acontecer. A disciplina em Gerenciamento de 
Projetos ganha cada vez mais destaque dentro da administração e tem-se 
transformado num fator relevante para prover rapidez e acuracidade de 
resultados na execução de projetos. Modelos de maturidade em gerenciamento 
de projetos vêm obtendo maior atenção dos profissionais da área de projetos, 
que buscam, cada vez mais, desenvolver competências organizacionais no 
gerenciamento dos mesmos. 
A necessidade de disseminar boas práticas e empregar uma metodologia 
padronizada ficou mais evidente, uma vez que o número de projetos que 
 
3 
 
falhavam era cada vez maior, acumulando prejuízos constantes à várias 
organizações no mundo todo. 
Alguns estudiosos das ciências gerenciais, enxergando então essa 
necessidade da sociedade, iniciam, principalmente a partir da década de 90, a 
elaboração de dezenas de guias e padrões de gerência de projetos, como o 
PMBOK, hoje o mais reconhecido mundialmente. Somente para termos uma 
ideia de grandeza dos modelos, guias e padrões criados ao longo do tempo, 
existem hoje mais de 30 modelos de maturidade. 
Cada modelo de maturidade em gerenciamento de projetos tem suas 
particularidades, mas é fato que a maioria dos modelos divide maturidade em 
cinco níveis. Cada um usa seus nomes específicos. Se formos pensar 
genéricamente, podemos classificar os níveis de maturidade da seguinte 
maneira: 
 Primeiro Nível: Ausência de gerenciamento formal, isso significa que não 
existe nenhum método ou procedimento formal para gerenciar projetos, ou 
seja, a organização não reconhece nenhum modelo e os projetos são 
desenvolvidos de acordo com as pessoas que trabalham nele. 
 Segundo Nível: O gerenciamento de projetos está definido, com alguns 
métodos ou ferramentas, mas sem nenhum acompanhamento formal, neste 
estágio é muito comum perceber organizações que tentam criar seus próprios 
modelos, mas que não dão sequência ao mesmo. 
 Terceiro Nível: O gerenciamento já possui algum tipo de integração entre 
os processos dentro da organização e utiliza, em alguns casos, processos mais 
complexos e elaborados, buscando um melhor planejamento das atividades e 
controle das mesmas. 
 Quarto Nível: O gerenciamento está completamente integrado, existem 
participação e suporte da alta administração, todos os objetivos, papéis e 
competências estão bem definidos e a fase de resistência a mudanças já se 
encerrou. Existem métricas definidas e reportadas dentro do processo. 
 Quinto Nível: As ineficiências do processo de desenvolvimento dos 
projetos são identificadas e, com uma gestão consistente, já é possível aplicar 
uma política de melhoria contínua durante este nível. 
 
 
4 
 
A adequação não precisa ser passo a passo. Muitas empresas utilizam a 
estratégia de aumentar seu nível de maturidade do primeiro ao quinto nível, 
porém, isso é completamente teórico e pouco efetivo. Seria mais eficaz se as 
organizações efetuassem as mudanças de curto e longo prazo separadamente, 
afinal o modelo já se chama Maturidade, e isso só se conquista de fato com 
muito trabalho e experiências vividas. 
Você, como gestor de uma organização e sabendo dos problemas que 
poderia ter ao não usar um padrão adequado, o que faria para identificar e 
conduzir o seu desenvolvimento em gestão de projetos e não confundir os 
diversos tipos e usos de modelos? 
Se raciocinarmos que um modelo de maturidade funciona como um guia e 
não como uma lei para a organização, de tal maneira que a empresa possa 
localizar onde está, como está e onde quer chegar, sempre tendo esse guia em 
mãos como base, fica mais fácil gerenciarmos o projeto de forma adequada. A 
palavra lei foi colocada propositalmente, pois muitos gerentes de projeto (os 
famosos By the book) acreditam que alguns modelos devem ser seguidos 
fielmente (independente do contexto da empresa, da equipe, do mercado, 
enfim, do ambiente em geral) e isso não pode ser visto assim. 
O guia serve para que o gerente de projetos siga um caminho, que pode 
não ser reto, mas que deve sempre levar ao objetivo final. PENSE NISSO! 
Neste módulo, vamos falar de cinco modelos de Maturidade em 
Gerenciamento de Projetos, seus conceitos e utilizações nas empresas, para 
que assim, possamos fazer uma analogia entre eles. 
 OPM3 (Organizational Project Management Maturity Model); 
 CMM (Capability Maturity Model); 
 PMMM (Project Management Maturity Model); 
 CMMI (Capability Maturity Model Integration); 
 Prado-MMGP (Modelo de Maturidade em Gerenciamento de Projetos) 
 
 
 
 
 
 
 
5 
 
Modelo OPM3 (Organizational Project Management Maturity Model); 
 
Com as organizações cada vez mais voltadas para o ambiente 
competitivo de novos projetos, os executivos iniciaram uma onda de 
investimentos para que suas organizações tivessem sucesso em seus projetos, 
buscando assim, retornos garantidos e potencializando a gestão estratégica da 
organização. 
Com isso, um grande número de profissionais enxergando essa 
oportunidade, trabalharam para que novos conceitos, produtos e serviços 
fossem oferecidos aos gestores, que agora se veem às voltas com os 
problemas de separar aquilo que realmente é útil daquilo que talvez não seja, 
no processo de mudanças de seu ambiente de projetos e suas iniciativas 
organizacionais. 
 
Neste contexto, no início de 2004, o PMI - Project Management Institute - 
lançou o seu Modelo OPM3, acrônimo de Project Management Maturity Model, 
desenvolvido a partir da pesquisa, como outros tantos modelos pré-existentes 
de avaliação de Maturidade Organizacional e, também, do apoio anônimo de 
aproximadamente 800 voluntários de mais de 35 países, inclusive do Brasil. 
 
6Entendendo como foi criado o modelo OPM3, percebemos que ele 
oferece uma estrutura capaz de traduzir estratégias das organizações em 
resultados de sucesso consistentes. Baseado no conceito de melhoria contínua 
na gestão de projetos, ele foi construído por meio do conceito de ‘Boas 
Práticas’, geralmente aceitas e previamente experimentadas por seus mentores 
iniciais e seguidores, o que facilita a utilização por parte de novos gestores que 
buscam incrementar rapidamente um ambiente organizacional de projetos mais 
consistente, além de aprimorar a operação de gestão de projetos. 
Lembramos que as organizações também possuem seus modelos de 
maturidade interna, ou seja, a organização como um todo possui seus 
processos estabelecidos e conforme vai se desenvolvendo e crescendo, ela 
muda seus processos para atingir um estado futuro desejado e o modelo 
OPM3 vem de encontro com as necessidades de maturidade, no que tange as 
práticas de Gerenciamento de Projetos. O OPM3 caminha pelas trilhas já 
demarcadas, pelas quais as organizações passam e pelos quais os marcos vão 
sendo atingidos, com o intuito de alcançar resultados mais efetivos e 
previsíveis na gestão de seus projetos. 
O modelo OPM3 é uma estrutura que proporciona benefícios visíveis para 
as organizações que o adotam: 
I - A organização passa a promover os projetos mais importantes e 
necessários, da maneira certa, e alinhados diretamente com a estratégia 
competitiva da empresa na economia global. 
II - Permite a flexibilidade de ser aplicado a diversos tipos de 
organizações, por meio de diferentes áreas de atuação, ramos de negócios, 
tamanhos, localizações geográficas e etc. 
III - Permite promover a conscientização e esclarecer a questão da 
maturidade organizacional para a alta direção. 
IV - Permite associar diretamente o sucesso da organização à gestão 
eficaz e eficiente de projetos. 
 
Para que a organização possa aplicar de forma correta o modelo OPM3, 
ela deve se basear em três fases, que estão inter-relacionados de modo 
sequencial: 
 
7 
 
1) O conhecimento por parte dos envolvidos dos componentes do modelo 
de maturidade; 
2) O questionário de autoavaliação do estágio de maturidade em que se 
encontra a organização; 
3) O processo de melhoria contínua, capaz de orientar gestores a 
movimentarem a organização de um estágio atual para um estágio futuro de 
maturidade. 
 
A Fase I está baseada no conhecimento dos elementos do modelo, que 
podem ser observados na forma de um repositório de informações com alguns 
elementos básicos: 
 As boas práticas geralmente aceitas e experimentadas por outros 
profissionais de organizações diferentes, irão auxiliar os gerentes, que estão 
implementando o modelo, a gerenciar e conduzir projetos com mais 
previsibilidade e chances de sucesso. 
 As capacidades internas e os requisitos necessários que devem estar 
ligados as boas práticas que serão utilizadas como modelo. 
 Indicadores Chave de Desempenho (conhecidos como KPIs), que 
possibilitam acompanhamento e medição dos resultados que a organização 
pretende atingir; 
 
A organização, como dito anteriormente, possui um grau de evolução de 
maturidade e a abrangência de alguns fatores sobre os quais precisamos de 
alguma forma controlar, para que assim a empresa possa medir o seu 
amadurecimento. Esses fatores podem ser, por exemplo, o portifólio, 
programas e projetos da organização. Para cada um destes fatores, vamos 
identificar estágios ao longo do tempo que estão como Padronização, 
Mensuração, Controle e Melhoria Contínua. 
A figura a seguir, ilustra estes componentes e a sua complexidade em 
busca da maturidade organizacional, que pode ser vista como uma jornada 
contínua de aprimoramento de processos por meio da aplicação de boas 
práticas de gerenciamento de projetos em cada um dos fatores estabelecidos 
anteriormente (portifólio, programas e projetos). 
 
 
8 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 1: Dimensões da Maturidade Organizacional por meio do Modelo OPM3 
 
A fase 2 de autoavaliação é o passo seguinte da aplicação do modelo, 
onde se faz alusão a um instrumento de autoavaliação, constituído por um 
questionário de escolhas binárias de (sim ou não), por meio do qual o usuário 
analisa e responde sobre a presença ou não de processos formais associados 
ao ciclo de vida do gerenciamento de projetos, tal como referenciado pelo Guia 
Project Management Body of Knowledge do próprio PMI. 
O resultado da aplicação do questionário é tratado como entrada do 
Modelo OMP3 que, de acordo com as respostas proporcionadas, define uma 
lista de boas práticas que, provavelmente, já estão presentes no modelo de 
gestão da organização, e uma segunda lista de boas práticas que seriam 
recomendadas à organização. 
O PMI oferece duas ferramentas para realizar a avaliação da organização: 
o “OPM3 Self Assessment”, que permite uma avaliação mais superficial da 
organização e o “OPM3 ProductSuite” onde a avaliação é conduzida por um 
consultor certificado. Ambas são cobradas. 
A avaliação é feita a partir de um questionário com 151 questões, veja o 
início do questionário: 
 
Portifólio 
 Aumento de Maturidade 
Programas 
Projetos 
Padronização Mensuração Controle Melhoria 
Contínua 
 
9 
 
 
O resultado é dado de forma a mostrar o nível de maturidade da 
organização em relação às várias categorias analisadas e às melhores práticas 
que devem ser melhoradas. 
 
 
 
A Fase 3 é o que chamamos de processo de melhoria contínua, onde o 
modelo já procura estabelecer, diante da lista de melhores práticas 
recomendadas, que a organização faça uma análise de viabilidade e 
priorização e, também, estabeleça um plano composto pela melhor sequência 
 
10 
 
de ações de melhoria, apropriadas às suas condições para alcançar maior 
maturidade. 
O ciclo de melhoria contínua, consolida-se pela execução desse plano de 
ação e pelo recomeço periódico da sequência proposta desde a fase de 
autoavaliação organizacional. 
A aplicação do Modelo OPM3 trata-se de uma jornada de aprimoramento 
que se sobrepõem aos objetivos imediatos e tangíveis da organização, para 
que, em uma amplitude maior, a equipe possa aprimorar os processos 
organizacionais gerais objetivando resultados mais adequados e prevísiveis 
nos projetos da organização. 
 
É importante lembrar que o modelo é baseado em um ciclo constituído de: 
Conhecimento, Avaliação e Aperfeiçoamento e, portanto, para realizar a 
avaliação da maturidade da organização, é necessário seguir o ciclo de estudo 
do modelo, realizar a avaliação, determinar o foco e o caminho das melhorias, 
avaliar as capacidades (seguindo os grupos de processos: Iniciar, Planejar, 
Executar, Controlar e Concluir), criar um plano para melhorias, implementar as 
melhorias e repetir o processo. 
 
O CMM (Capability Maturity Model) 
O CMM (Capability Maturity Model), por ser o precursor dos modelos de 
maturidade, é voltado à entrega de processos técnicos (indústria de softwares), 
extremamente difundido e aperfeiçoado entre essa indústria. Nas áreas de 
desenvolvimento e engenharia de software, os modelos CMM (Capability 
 
11 
 
Maturity Model) e CMM-I (Capability Maturity Model Integration), têm sido 
amplamente os mais utilizados. Estes modelos são baseados em conceitos de 
níveis de maturidade e requisitos estruturais de processos, eles têm permitido 
que as organizações possam se estruturar em relação aos seus níveis de 
maturidade e capacitação em gestão de projetos de software. 
O Modelo de Maturidade CMM fornece às organizações de software umguia de como obter controle em seus processos para desenvolver e manter o 
mesmo, e mais do que isso, mostra também como evoluir em direção a uma 
cultura de engenharia de software com excelência de gestão. O CMM foi 
projetado, inicialmente, para guiar as organizações de software no processo de 
seleção das estratégias de melhorias, identificando as questões mais críticas a 
serem trabalhadas pelas organizações. A área de software teve um avanço 
muito grande na área de projetos, e o CMM baseia sua estrutura em estágios e 
princípios de qualidade de produto dos últimos sessenta anos. 
Precisamos entender que, mesmo que os profissionais envolvidos nos 
projetos de software tenham pleno conhecimento de seus problemas, eles 
podem discordar quanto a importância das melhorias. Sem uma estratégia 
organizada, é difícil a gerência e a equipe de funcionários chegarem a um 
consenso sobre a prioridade dessas atividades. Para se conseguir resultados 
consistentes a partir de esforços em melhoria de processos, é necessário 
projetar um caminho evolutivo que incremente, em fases, a maturidade do 
processo de software da organização. 
Os modelos CMM e CMM-I foram desenvolvidos pela Carnegie Mellon 
University em parceria com a SEI – Software Engineering Institute. O CMM, 
cuja versão integral foi publicada em 1993, apresenta cinco níveis de 
maturidade, sendo cada um deles caracterizado por um conjunto de áreas-
chave, cuja estruturação é considerada necessária para o projeto e 
desenvolvimento de softwares. Os cinco níveis de maturidade contemplados 
pelo modelo CMM são: 
 
12 
 
 
 
Inicial - O processo de software é caracterizado como “ad hoc” e até 
mesmo, ocasionalmente, caótico. Poucos processos são definidos e o sucesso 
depende de esforço individual. 
Repetitivo - Os processos básicos de gestão de projeto são 
estabelecidos para acompanhar custo, cronograma e funcionalidade. A 
necessária disciplina do processo existe para repetir sucessos anteriores em 
projetos com aplicações similares. 
Definido - O processo de software para as atividades de gestão e 
engenharia é documentado, padronizado e integrado em um processo de 
software padrão para a organização. Todos os projetos utilizam uma versão 
aprovada do do mesmo para desenvolver e manter software. 
Gerenciado - Medidas detalhadas do processo de software e da 
qualidade do produto são realizadas. O processo e os produtos de software 
são quantitativamente compreendidos e controlados. 
Otimizado - A melhoria contínua do processo, é propiciada pelo feedback 
quantitativo do processo e pelas idéias e tecnologias inovadoras. 
O CMM trabalha com Áreas de Processo-chave (KPA), que identifica um 
conjunto de atividades relacionadas que buscam atingir um conjunto de metas 
consideradas importantes, quando realizadas em conjunto. 
 
Nível 1 - O Nível Inicial 
Neste nível, devemos pensar na organização sem um ambiente estável 
para o desenvolvimento e manutenção de software, sem práticas de gestão 
bem estabelecidas, e onde os benefícios das boas práticas, mesmo que 
Inicial 
(Caos)
Repetitivo
Definido
Gerenciado
Otimizado
 
13 
 
executados, acabam sendo descartados por um planejamento ineficiente e por 
uma realidade onde os compromissos assumidos são sempre reativos. 
Entende-se por compromissos reativos aqueles que todos nós conhecemos e 
que entram no nosso dia a dia sem que haja nenhum planejamento prévio. 
É comum, dentro das organizações com esse nível de maturidade, 
quando em meio a uma crise, que todos os projetos típicos abandonam os 
procedimentos que foram planejados anteriormente e partem para a 
codificação e testes (e que sabemos não terá um bom resultado final). 
O sucesso depende inteiramente de ser ter um gerente excepcional e 
uma equipe de software madura e eficiente. 
Em alguns casos, percebemos que gerentes de software eficientes, que 
dispõem de poder e experiência, podem resistir momentaneamente as 
pressões de recorrer a atalhos no processo, mas isso faz com que a 
organização se torne dependente desse gerente. 
 
Em resumo, a organização que vive o nível 1 possui sempre resultados 
imprevisíveis em relação a seus projetos, pois o processo de software é 
constantemente alterado a medida em que o trabalho avança (é o que 
chamamos de “ad hoc”). 
Cronogramas, orçamentos, funcionalidades e qualidade do produto são 
geralmente cheios de surpresas e imprevistos. O desempenho depende da 
capacidade dos indivíduos e varia de acordo com as suas habilidades, 
conhecimentos e motivações dos envolvidos. 
 
Nível 2 – O Nível Repetitivo 
Neste nível, as políticas de gestão de projeto de software e os 
procedimentos para implementá-las já estão estáveis, é onde já encontramos 
um nível de planejamento e de gestão de novos projetos que são definidos de 
acordo com a experiência adquirida em projetos similares, com a 
institucionalização dos processos para os projetos de software, as 
organizações conseguem repetir suas práticas bem sucedidas desenvolvidas 
em projetos anteriores, apesar dos processos específicos implementados pelos 
projetos serem diferentes. 
 
14 
 
Um processo efetivo pode ser caracterizado como documentado, robusto, 
treinado, medido e sempre com possibilidades de melhorias. 
Os projetos nas organizações de nível 2 possuem controles básicos de 
gestão de software e, com isso, seus compromissos do projeto são baseados 
em resultados observados em projetos anteriores, mas nunca esquecendo dos 
requisitos atuais. 
Os gerentes de projeto acompanham custos, cronogramas e 
funcionalidades do software e, com isso, os problemas são identificados 
quando surgem e tratados de forma adequada, sem fugir dos padrões pré-
estabelecidos. Nesse nível, os produtos de trabalho são armazenados de forma 
criteriosa e a integridade dos mesmos é controlada (o que chamamos de 
ambiente controlado com controle de configuração). 
O nível 2 pode ser resumido como disciplinado se levarmos em 
consideração que, o planejamento e o acompanhamento do projeto já são 
estáveis e os sucessos mais recentes podem ser repetidos. Nesse nível os 
processos estão sob um controle efetivo de um sistema de gestão de projeto, 
seguindo planos realistas baseados em experiências anteriores. 
 
Nível 3 – O Nível Definido 
No Nível Definido, o processo padrão de desenvolvimento e manutenção 
de projetos da organização é documentado, inclusive a gestão de processos. 
É nesse nível que os processos passam a ser utilizados e, muitas vezes, 
alterados para apoiar os gerentes de projeto e o pessoal técnico, contribuindo 
para que possam atuar de forma mais efetiva. 
Ao padronizar seus processos, a organização exercita práticas de 
engenharia de software mais efetivas e de forma controlada, para isso é 
formada uma equipe responsável pelas atividades de processo de software da 
organização, a SEPG (Software Engineering Process Group), que fica 
responsável pelo programa de treinamento, que irá garantir aos gerentes e 
membros de equipe os conhecimentos e as habilidades necessárias para o 
cumprimento de suas funções. 
Neste nível, os projetos adaptam o processo de software padrão da 
organização para desenvolverem seus próprios processos, que consideram as 
características únicas de cada projeto. Esse processo concebido é referido no 
 
15 
 
modelo CMM como “processo de software definido do projeto”. Um processo 
de software definido contém uma integração coerente do desenvolvimento de 
software com os processos de gestão bem definidos. 
Um processo bem definido pode ser caracterizado como possuidor de 
critérios de disponibilidade, entradas, padrões e procedimentospara realização 
do trabalho, mecanismos de verificação (tais como revisões por pares), saídas 
e critérios de finalização. Como o processo de software é bem definido, a 
gerência tem uma boa percepção do progresso técnico em todos os projetos. 
O nível 3 pode ser resumido como uma padronização consistente, pois 
tanto as atividades de gestão de projetos como as de produção de software 
são estáveis e repetíveis. Esse nível é marcado pelo entendimento global da 
organização com relação as atividades, regras e responsabilidades decorrentes 
do processo de construção e gerenciamento de projetos. 
 
Nível 4 – O Nível Gerenciado 
No Nível Gerenciado, a organização estabelece metas quantitativas de 
qualidade para os produtos e processos de construção de software. Nesse 
nível, a produtividade e a qualidade são medidas nas atividades importantes 
dos processos em todos os projetos, como parte de um programa 
organizacional de medições. 
É importante a criação de um banco de dados de processos abrangendo 
toda a organização, que será utilizado para coletar e analisar os dados 
disponíveis dos processos de software definidos dos projetos. No nível 4, os 
processos de software já devem ser feitos por meio de ferramentas de apoio, 
para assim gerarem medições consistentes e bem definidas. Essas medições 
vão estabelecer as bases para avaliar os processos e os produtos de software 
do projeto. Os projetos possuem controle sobre seus produtos e processos, 
reduzindo a variação no desempenho destes últimos, para atingir limites 
quantitativos aceitáveis. 
As variações significativas no desempenho dos processos podem ser 
distinguidas das variações aleatórias (ruídos), particularmente dentro de linhas 
de produtos estabelecidas. 
Neste nível, os riscos decorrentes da introdução de mudanças são 
conhecidos e, cuidadosamente, gerenciados. Em resumo, a organização 
 
16 
 
trabalha em um ambiente totalmente previsível, porque os processos são 
medidos e operam dentro de limites mensuráveis, permitindo assim que a 
organização consiga prever as tendências na qualidade dos produtos e dos 
processos dentro das fronteiras quantitativas desses limites. 
Mas devemos saber que, mesmo em um ambiente assim, alguns 
imprevistos e limites podem ser excedidos, o que é normal em uma 
organização dinâmica e madura, mas nesses casos, algumas medidas são 
tomadas para corrigir a situação e o projeto segue seu curso de entrega com 
alta qualidade. 
 
Nível 5 – O Nível Otimizado 
No nível em que a organização se encontra em processo de otimização, o 
foco principal é no processo de melhoria contínua de processos em busca de 
excelência. Nesse estágio, a organização já possui meios de identificar as 
oportunidades de melhoria e fortalecer o processo de maneira pró-ativa, com o 
objetivo de prevenir a ocorrência de falhas. 
Os dados coletados sobre a efetividade de processo de software são 
utilizados para realizar análises de custo x benefício das novas tecnologias e 
das mudanças propostas no processo de software da organização. As 
inovações decorrentes das melhores práticas de engenharia de software são 
identificadas e transferidas para a organização como um todo. 
As equipes de projeto de software das organizações de Nível 5 analisam 
as falhas para determinar suas causas. Os processos de software são revistos 
para que haja uma prevenção antecipada de problemas já conhecidos e que, 
normalmente, se repetem. 
Neste estágio, a equipe se preocupa em documentar detalhadamente as 
lições aprendidas, para que as mesmas sejam disseminadas para outros 
projetos, em resumo este é o estágio final desejado por todas as organizações 
que prezam a qualidade e o controle de seus projetos, pois aqui as equipes 
estão, continuamente, se esforçando para melhorar a abrangência de sua 
capacidade de execução de projetos por meio da melhora constante dos 
processos. As melhorias ocorrem sempre por avanços incrementais nos 
processos já existentes e também por meio de inovações, que utilizam novos 
métodos e tecnologias. 
 
17 
 
 
 
Modelo da Estrutura CMM na versão do SEI 
 
Estrutura do Capability Maturity Model 
 
Vimos então, que o CMM é uma estrutura que representa um caminho 
para melhoria de processos, recomendada para organizações de software que 
desejam melhorar seus processos de desenvolvimento do mesmo. Com esse 
modelo, podemos ter as equipes de avaliação utilizando o CMM para identificar 
pontos fortes e oportunidades de melhoria na organização e para identificar 
riscos na seleção de diferentes prestadores de serviço Com isso, os gerentes e 
técnicos poderão utilizar o CMM para entender as atividades necessárias ao 
planejamento e implementação de um programa de melhorias no processo de 
 
18 
 
software de suas organizações e, finalmente, os grupos de melhoria de 
processo, como por exemplo, o Grupo de Processos (SEPG), que poderá 
utilizar o CMM como um guia para ajudá-los a definir e melhorar o processo de 
software de suas organizações. 
 
Você pensando em CMM 
Se é um processo de maturidade, por que as empresas pulam processos 
para atingir o nível 5? 
Como já vimos anteriormente, os níveis de maturidade no CMM 
descrevem as características de uma organização em um determinado nível de 
maturidade. Cada nível constrói a base para os níveis seguintes alavancarem a 
implementação de processos de forma efetiva e eficiente. 
As organizações podem, entretanto, usar proveitosamente os processos 
descritos em um nível de maturidade mais elevado que aquele em que se 
encontram, isso faz elas elevarem seu nível? Vamos usar como exemplo na 
engenharia de processos, a análise de requisitos, projeto, codificação e teste, 
que não é discutida até o nível 3, ainda que até mesmo as organizações de 
Nível 1 devam realizar essas atividades. 
As organizações de Nível 1 ou Nível 2, ao prescreverem os passos que 
deveriam trilhar para passar para os níveis superiores, devem ter o cuidado de 
estabelecer um conjunto de processos de desenvolvimento com os atributos do 
nível superior, mesmo que não possam alcançar seus potenciais completos, 
antes que uma base adequada seja estabelecida. 
Um processo de revisão por pares não pode ser totalmente efetivo, a 
menos que sejam implementadas de forma consistente, mesmo quando os 
“incêndios” colocam o projeto em risco. Os níveis de maturidade descrevem os 
problemas que predominam em cada nível. Os problemas predominantes nas 
organizações de Nível 1 são gerenciais; os outros problemas tendem a ser 
encobertos pelas dificuldades de planejamento e gestão dos projetos de 
software. 
Em resumo, pular níveis de maturidade não é recomendado, porque cada 
nível constitui a base necessária, a partir da qual, se alcança o próximo nível. O 
CMM identifica os níveis por meio dos quais uma organização deve se 
desenvolver para estabelecer uma cultura de excelência, e se os processos 
 
19 
 
não possuem as bases adequadas, eles vão falhar no ponto extremo onde 
estão mais carentes; 
“Durante as situações de Stress” 
 
Uma organização de Nível 1, que está tentando implementar o processo 
definido no Nível 3 antes de ter estabelecido o processo repetível Nível 2, 
geralmente é mal sucedida, porque os gerentes de projeto estão pressionados 
por problemas de controle no custo e cronograma de projeto. Esta é a razão 
fundamental para focar em gestão de projeto antes de implementar a 
engenharia de processo. Pode parecer que a definição e a implementação da 
engenharia de processo devem acontecer antes da gestão de processo 
(especialmente aos olhos do pessoal técnico), mas, sem a disciplina gerencial,a engenharia de processo fica prejudicada pelas pressões de cronograma e de 
custo. 
 
Uma organização que está tentando implementar o processo gerenciado 
Nível 4, sem os fundamentos do processo definido no Nível 3, geralmente é 
mal sucedida, porque não há bases comuns para a interpretação das medidas 
sem os processos definidos. Se, por um lado, os dados podem ser coletados 
individualmente pelos projetos, por outro, poucas medidas são significativas no 
âmbito de todos os projetos, não tendo condições de fazer crescer, 
substancialmente, o entendimento do processo de software. 
 
 
Uma organização que está tentando implementar um processo otimizado 
Nível 5, sem as bases do processo gerenciado Nível 4 e 3, provavelmente está 
fadada ao fracasso, devido a falta de entendimento do impacto das mudanças 
no processo. Sem controlar o processo dentro de fronteiras estatisticamente 
estreitas, a organização está sujeita a muita interferência nos dados, para que 
assim se possa determinar objetivamente se uma dada melhoria de processo 
tem algum efeito. PENSE na frase abaixo. 
 
 
20 
 
“Mas, mesmo assim o número de empresas que pulam os níveis por 
imposição do mercado é muito grande”. 
Para cada nível de maturidade, há cinco tipos de checklist: 
 TypeSD: Descrição 
 Política: 
Descreve o conteúdo da política e objetivos KPA recomendado pelo 
CMM. 
 Padrão: 
Descreve o conteúdo recomendado de produtos de trabalho descrito 
na CMM. 
 Processo: 
Descreve o conteúdo da informação do processo recomendado pelo 
CMM. As listas de verificação do processo são ainda mais refinadas 
em listas de verificação para: 
 Papéis 
 Critérios de entrada 
 Insumos 
 Atividades 
 Saídas 
 Critérios de saída 
 Revisões e auditorias 
 Produtos de trabalho gerido e controlado 
 Medições 
 Procedimentos documentados 
 Treinamento 
 Ferramentas 
Procedimento: 
Descreve o conteúdo recomendado de procedimentos documentados 
descrito na CMM. 
 Visão geral: 
Fornece uma visão geral de um nível de maturidade inteiro. As listas 
de verificação da visão geral são ainda mais refinadas em listas de 
verificação para: 
 Fins KPA (Key Process Areas) 
 Metas KPA 
 Políticas 
 Padrões 
 Descrições de processo 
 Procedimentos 
 Treinamento 
 Ferramentas 
 Revisões e auditorias 
 Produtos de trabalho gerido e controlado 
 Medições