Artigo - CSTI com Maturidade em Projetos

EDGAR AUGUSTO DE ALMEIDA SANTOS
GERENCIAMENTO DE PROJETOS COM PMBOK
POR UMA CENTRAL DE SERVIÇOS DE TI BASEADA EM ITIL
Especialização em Gerenciamento de Projetos
São Paulo
2016

UNINOVE – Universidade Nove de Julho
EDGAR AUGUSTO DE ALMEIDA SANTOS
GERENCIAMENTO DE PROJETOS COM PMBOK
POR UMA CENTRAL DE SERVIÇOS DE TI BASEADA EM ITIL
São Paulo
2016
Artigo científico em caráter do Trabalho de
Conclusão de Curso (TCC) apresentado a UNINOVE –
Universidade Nove de Julho como parte dos requisitos
acadêmicos para aprovação no curso de pós-graduação
Lato-Sensu Master in Project Management, sob
orientação do Prof. Ms. Airton Rodrigues.

RESUMO
A hipótese adotada neste estudo propôs uma análise de competição entre uma Central
de Serviços de TI (CSTI) externa, que pode apresentar benefícios ao gerenciar projetos de
infraestrutura que habitem em sua esfera operacional diária, em comparação a uma
consultoria de projetos de TI, que atende a demandas específicas e casuais para auxiliar
organizações no preenchimento dos respectivos requisitos de negócio.
A revisão bibliográfica realizada abrangeu as características comuns de uma CSTI e de
uma consultoria especializada em gerenciamento de projetos, as metodologias para avaliação
do nível de maturidade, e a publicação de um plano de ação genérico para a elevação do nível
de maturidade dentro do modelo MMGP – Modelo de Maturidade para Gerenciamento de
Projetos, criado por Darci Prado.
Com base no conteúdo analisado, o resultado da hipótese provou-se aceitável, de
acordo com a estrutura organizacional e o nível de maturidade para gerir de projetos que a
CSTI encontra-se para competir de maneira saudável com consultorias especializadas em
gerenciamento de projetos.
Palavras-chave: Central de Serviços de TI (CSTI), Competitividade, Maturidade,
Projetos, Infraestrutura de TI.
ABSTRACT
The presented hypothesis in this study offered a competition analysis about efficiency
in implementing IT infrastructure projects between an external IT Services Center (ITSC) and
a specialized IT Project Consultancy, where the ITSC could add as value as the consultancy
in order to their daily operational routine managing IT processes and services inside the
client’s IT infrastructure, instead a consultancy that typically attend to eventual and specific
tasks and projects to help the organization fulfill on-demand business requirements.
This bibliographic review covered the common characteristics of an ITSC and a
specialized IT Project Consultancy, some methodologies to assess project management
maturity level, and a generic action plan to raise the maturity level in the model MMGP –
Modelo de Maturidade para Gerenciamento de Projetos, by Darci Prado.

The analysis result showed that the hypothesis is acceptable depending on the ITSC
organizational structure and maturity level to manage projects, making it able to face a
specialized IT Project Consultancy in a healthy competition.
Keywords: IT Services Center (ITSC), Competitivity, Maturity, Projects, IT
Infrastructure.

AGRADECIMENTO
Gostaria de agradecer à todos que me apoiaram ao longo das fases mais importantes
desta jornada, em especial ao meu colega de trabalho e, sobretudo, grande amigo Thiago de
Jesus Sousa, por sempre ter acreditado em meu potencial, ter me ofertado todo o suporte
necessário para desenvolver esse estudo, além de ter me mentorado sob sua gestão,
contribuindo fortemente na formação do profissional que sou atualmente; e também agradeço
à meu querido amigo e guerreiro Bruno Lopes de Albuquerque, que sempre esteve ao meu
lado em momentos bons e ruins, e que embarcou nessa jornada junto a mim, mesmo que
distante.

DEDICATÓRIA
Dedico esta vitória à minha mãe, Silvia Severino de Almeida, que me ensinou desde
cedo que desistir não é uma opção, transformando-me na pessoa que sou hoje; e à minha
companheira, Micheli Karoline da Silva Santos, que sempre manteve-se firme sobre as
consequências positivas e negativas de nossas decisões, buscando incansavelmente a
felicidade conjunta.
Também a dedico à todos os profissionais atuantes na área de Tecnologia da
Informação e Projetos, que diariamente encontram motivação para persistir em meio às
diversas dificuldades que surgem.

SUMÁRIO
1. INTRODUÇÃO....................................................................................................8
2. REVISÃO TEÓRICA ........................................................................................10
2.1. Gestão de Serviços de TI baseada na ITIL .....................................................10
2.1.1. Ciclo de Vida no Gerenciamento de Serviços de TI.................................10
2.1.2. Central de Serviços de TI como uma Parceira de Negócios.....................12
2.2. Gestão de Projetos de TI baseada no PMBoK................................................14
2.2.1. Ciclo de Vida no Gerenciamento de Projetos...........................................14
2.2.2. A Influência Cultural nas Estruturas Organizacionais em Projetos..........17
2.3. Modelos de Maturidade na Gestão de Projetos...............................................22
2.3.1. CMM – Capability Maturity Model .........................................................22
2.3.2. PMMM – Project Management Maturity Model......................................24
2.3.3. OPM3™ – Organizational Project Management Maturity Model ...........25
2.3.4. MMGP – Modelo de Maturidade em Gerenciamento de Projetos ...........26
3. METODOLOGIA...............................................................................................29
4. DISCUSSÃO DOS RESULTADOS..................................................................30
5. CONSIDERAÇÕES FINAIS .............................................................................33
6. REFERÊNCIAS BIBLIOGRÁFICAS ...............................................................34

8
1. INTRODUÇÃO
O cenário tradicional em organizações de qualquer porte e segmento já é um velho
conhecido: enorme competividade.
A competitividade é o combustível que impulsiona as empresas a buscarem a liderança
em meio aos desafios e turbulências que encontram durante a longa jornada que percorrem.
“Citius, Altius, Fortius”, que significa “mais rápido, mais alto, mais forte” em latim, é um
lema olímpico que simboliza, de uma maneira bastante concisa, o espírito competitivo que as
empresas precisam levar consigo.
Entretanto, conquistar a liderança é um objetivo de todos os concorrentes, o que exige
muita competência, além de disposição, versatilidade e recursos. Tal competência abrange
áreas técnicas e gerenciais, estratégicas e operacionais, focando em planejamento, execução e
monitoria com validações constantes de efetividade e eficiência. A disponibilidade de
recursos para planejar, executar e monitorar as metas que antecedem um objetivo
organizacional sempre envolve pessoas, capital e tecnologia.
Dentre esses recursos, a tecnologia é um dos recursos mais reconhecidos como
diferencial competitivo para apoio às decisões estratégicas definidas pelas empresas para
alcance da almejada liderança. Geralmente, a tecnologia é utilizada por meio de sistemas de
informações que automatizam processos, geram maior confiança quanto à integridade dos
dados que compõe relatórios gerenciais, agilizando a tomada de decisão em todas as camadas
da hierarquia. Infelizmente, a tecnologia é tradicionalmente considerada apenas como uma
área de apoio, que não está fortemente ligada ao coração do negócio (core business), e esta
visão é a qual as organizações adotam ao decidir que as atividades relacionadas a essa área
devam ser terceirizadas. Partindo deste tipo de oportunidade, surgiram as consultorias de
Tecnologia da Informação e Comunicação (TIC).
As consultorias que prestam serviços na área de infraestrutura de tecnologia
comumente focam seus esforços em suporte à infraestrutura operacional, hardware e
administração de aplicações e softwares de alta performance, que exigem alta disponibilidade
e possuem nível elevado criticidade do ponto de vista do negócio. Mas nem todas possuem
capacidade para ofertar todos estes serviços, variando, então, de acordo com o porte e visão
estratégia da consultoria. As consultorias que tem a capacidade necessária para prestar esses
serviços com qualidade têm a oportunidade de negociar contratos que envolvem a oferta de
uma Central de Serviços de TI (CSTI) para o negócio.

9
Uma Central de Serviços de TI que adota uma cultura centralizada no cliente, ao invés
de foco em tecnologia, tende a equilibrar melhor seus fornecedores externos, utilizam
modelos mistos para entrega de serviços (outsourcing e outtasking), além de apresentarem
maior competitividade por obterem diversos fornecedores, orientarem-se a processos e
negociar a demanda e recursos junto aos seus clientes (RODRIGUES, 2010).
Este posicionamento mantém a CSTI extremamente próxima a vivência operacional
cotidiana de seus clientes, muitas vezes adquirindo o conhecimento necessário para executar
diversos tipos de atividades, produzindo documentos e procedimentos com nível de
excelência e, ainda, autonomia para propor melhorias em processos e fluxos, influindo a
diminuição de gastos e/ou o aumento de produtividade.
Todavia, a CSTI não é uma função que exija considerável embasamento em projetos,
algo que seria bastante positivo para a elevação de seu posicionamento estratégico na visão de
seus clientes. Devido a essa deficiência, seus clientes buscam outras consultorias, estas já com
foco e conhecimento profundo em projetos, para realizarem o planejamento, execução e
encerramento de projetos que envolvam a implantação de uma nova tecnologia, por exemplo,
ou a atualização de outra já em produção em um ambiente operacional que a CSTI já conhece
a fundo pela proximidade que existe entre a CSTI e o cliente, decorrente da prestação dos
serviços de TI. Após o encerramento de um projeto, existe algo conhecido como repasse
operacional, onde a CSTI assume a responsabilidade pela disponibilidade da aplicação ou
ferramenta implantada por tal consultoria especializada em projetos – algo este que não seria
necessário, caso a própria CSTI fosse executora do projeto.
Dentro deste contexto, observa-se que seria possível a própria CSTI implementar
projetos em seu cliente, caso esta detivesse o devido conhecimento e recursos para tanto.
Então, como uma Central de Serviços de TI externa pode criar a maturidade necessária para
implementar projetos de infraestrutura baseados no guia Project Management Body of
Knowledge (PMBoK) em seu cliente?
Esta é a problemática direcionadora deste estudo, que visa entender como é possível
elevar a maturidade de Centrais de Serviços de TI na gestão de projetos por existir diversas
oportunidades de atuar neste nicho, mas que possuem maior atuação em ambientes
operacionais.

10
2. REVISÃO TEÓRICA
2.1. Gestão de Serviços de TI baseada na ITIL
A Information Technology Infrastructure Library (ITIL, Biblioteca de Infraestrutura
de TI) é o guia de boas práticas mais utilizado no mundo para gerenciar processos e serviços
de TI nas organizações, sendo desenvolvido, gerenciado e publicado pelo Office of
Government Commerce (OGC), que visa conceder uma metodologia consistente e relevante
aos gerentes de TI para demonstrar diariamente às diretorias que sustentam a governança
organizacional que a área de tecnologia da informação deve ser compreendida como uma
parceira de negócios, e não somente uma executora tática-operacional que deve suportar
decisões estratégicas.
A forte disseminação das boas práticas de infraestrutura em TI, que a ITIL apresentou,
indicou às organizações o melhor caminho a ser trilhado para o alcance dos objetivos gerais
que a área de tecnologia deve atingir para realizar seu papel de parceira de negócios no
contexto organizacional. Porém, apenas indicou. A ITIL é apenas um guia com sugestões
estruturadas por meio de uma metodologia, mas não é um padrão a ser seguido. O padrão
ISO/IEC 20.000 (Gestão de Serviços de TI), desenvolvido pela International Organization for
Standardization (ISO), foi criado com base na metodologia ITIL com a ambição de criar
diretrizes e regras que possam certificar uma organização ou departamento de TI quanto à sua
competência na entrega de serviços e produtos com nível mínimo de excelência pré-definido a
ser cumprido.
Um serviço é caracterizado por ser intangível (não pode ser provado antes de ser
adquirido, nem pode ser sentido, visto ou ouvido). A versão três (03) da ITIL (mais atual,
publicada em 2011), engloba cinco (05) fases (grupos de macroprocessos) que gerenciam o
ciclo de vida de um serviço; cada fase representa um livro do guia de boas práticas publicado
separadamente.
2.1.1. Ciclo de Vida no Gerenciamento de Serviços de TI
As fases do ciclo de vida de um serviço, na visão do guia pela OGC (2011), são:
I. Estratégia de Serviço (Service Strategy): focando na estratégia de negócio,
esta publicação concede princípios e ferramentas úteis para identificar,
selecionar e priorizar oportunidades (produtos e serviços) que possam ser

11
oferecidos pela organização. Nesta fase, são elaboradas as políticas, diretrizes e
processos para gestão de serviços que influenciam em todo o ciclo de vida.
II. Desenho de Serviço (Service Design): orienta o desenvolvimento de produtos
e serviços de TI e a serem fornecidos por uma organização, e os processos
necessários para gerenciar tais serviços, por meio de métodos e princípios que
transformam objetivos estratégicos em um portfólio de soluções, envolvendo
tanto serviços novos quanto à revisão e melhoria dos atuais.
III. Transição de Serviço (Service Transition): proporciona as capacidades
necessárias para que um produto ou serviço idealizado na Estratégia e
planejado no Desenho seja implementado com eficiência e de forma
transparente, controlando riscos de falhas, para que a Operação de Serviço
possa mantê-lo na rotina diária da organização pós-implementação.
IV. Operação de Serviço (Service Operation): busca alcançar eficiência e
efetividade na entrega de serviços para garantir que o valor enxergado pelo
cliente seja mantido. Fornece diretrizes detalhadas sobre processos, métodos e
ferramentas para controlar perspectivas reativas e proativas, apoiando gerentes
e profissionais a gerenciar disponibilidade de serviços, controlar demandas,
melhorar a utilização de capacidade e corrigir problemas.
V. Melhoria Contínua de Serviço (Continual Service Improvement): cria,
mantém o valor percebido pelo cliente por meio da combinação de princípios,
práticas e métodos que auxiliam as organizações a enxergarem melhorias
executadas ao longo do ciclo de vida de um serviço, por meio do modelo
PDCA (Plan, Do, Check, Act).
Fonte: GreenPages, 2016

12
2.1.2. Central de Serviços de TI como uma Parceira de Negócios
A Diretoria de Tecnologia da Informação (DTI) de uma organização é a responsável
pela definição de diretrizes e elaboração de planos a serem seguidos, além de metas e
objetivos a serem atingidos para que esta mantenha-se competitiva no mercado com apoio da
tecnologia. Para tanto, existe o framework CobIT (Control Objectives for Information and
related Technology) que apresenta as melhores práticas de Governança de TI nas
organizações, facilitando a execução das tarefas de cunho estratégico, cuja responsabilidade é
da alta direção.
A visão estratégica de uma organização determina quais são os setores que fazem
parte da área central do negócio (core business). As áreas de suporte, que não são
consideradas integrantes do core business, tendem a ser terceirizadas (como Recursos
Humanos, Jurídico, Marketing, Facilities, e a própria TI, por exemplo), decisão essa que não
as menospreza se for levado em consideração todos os benefícios que são gerados pela
terceirização de uma área importante, mas não essencial, de uma empresa, pois englobam:
elevação do nível de qualidade, redução de custos e riscos, minimização de processos
seletivos e gestão de pessoas, e ausência da necessidade de treinamentos pela aquisição do
conhecimento pronto que o provedor possui e utiliza para entregar serviços prontos.
Santos (2009) indica que é necessário integrar os processos e controles do provedor de
TI externo (CSTI) com as diretrizes de Governança de TI do cliente para implantar projetos
de serviços de TI – atendendo a requisitos internos e externos de conformidade e excelência.
Essa integração deve melhorar a performance da organização (cliente) por via de outra
(CSTI), aumentando suas principais forças e competências.
Consultorias que prestam serviços na área de infraestrutura de TI comumente focam
seus esforços em suporte à infraestrutura operacional, hardware e administração de aplicações
e softwares de alta performance, que exigem alta disponibilidade e possuem nível elevado
criticidade do ponto de vista do negócio. Mas nem todas possuem capacidade para ofertar
todos estes serviços, variando, então, de acordo com o porte e visão estratégia da consultoria.
As consultorias que tem a capacidade necessária para prestar esses serviços com qualidade
têm a oportunidade de negociar contratos que envolvem a oferta de uma Central de Serviços
de TI (CSTI) para o negócio.
Uma Central de Serviços de TI que adota uma cultura centralizada no cliente, ao invés
de foco em tecnologia, tende a equilibrar melhor seus fornecedores externos, utilizam

13
modelos mistos para entrega de serviços (outsourcing e outtasking), além de apresentarem
maior competitividade por obterem diversos fornecedores, orientarem-se a processos e
negociar a demanda e recursos junto aos seus clientes (RODRIGUES, 2010).
A Operação de Serviço é constituída de tarefas contínuas e processos repetitivos,
sendo aplicados diariamente na rotina de uma organização. Uma CSTI está presente nessa
fase do ciclo de vida, onde é realizado todo o suporte aos serviços de TI que são utilizados
pelo cliente, por meio de processos, indicadores, papéis e funções, além de Acordos de Nível
de Serviço (Service Level Agreements, SLAs) pré-definidos. Após o encerramento de um
projeto, existe algo conhecido como repasse operacional, em que a CSTI assume a
responsabilidade pela disponibilidade da aplicação, ferramenta ou serviço implantado por uma
consultoria especializada em projetos – algo este que não seria necessário, caso a própria
CSTI fosse a executora do projeto.
Um projeto é conhecido por ser temporário e possuir datas definidas para início e
término, visando atender aos objetivos de prazos, custos e escopos que trarão um resultado
específico que gere benefícios ao cliente. Para atingir resultados melhores no
desenvolvimento de projetos, é indicado que seja utilizada uma metodologia padrão na
organização que os implementa. Existem diversas práticas para a execução de projetos. As
mais conhecidas são as que estão descritas no guia PMBoK (a ser tratado logo nos tópicos
seguintes). Porém, dentro do contexto em que serviços são gerenciados por equipes de
operação, é comum que projetos sejam realizados dentro de processos existentes na gestão
diária dos serviços (presentes na ITIL), e também pelo do CobIT, que fornece processos para
avaliação de maturidade na gestão de projetos de serviços de TI e execução destes projetos
por meio da fase Transição de Serviço, integrante do ciclo de vida da biblioteca ITIL.
A gestão de projetos de TI por meio dos processos da Transição de Serviços ofertados
pela ITIL (frequentemente utilizada em CSTIs), quando bem elaborada, garante uma operação
eficaz em termos de processos, resultados financeiros e de relacionamento do provedor
(CSTI) com o cliente, possibilitando que a Operação de Serviço seja iniciada e mantida com
credibilidade e rentabilidade (SANTOS, 2009).
É extremamente comum a CSTI realizar projetos, de pequeno e médio porte (atuando
como provedor de serviços), no ambiente operacional de seu cliente. Esses projetos
contemplam, em sua maior parte, a busca pela melhoria contínua (PDCA) no ambiente, por
meio de inovação nos processos operacionais para redução de custos, otimização dos recursos
humanos nas atividades cotidianas e facilidade na execução de tais tarefas.

14
2.2. Gestão de Projetos de TI baseada no PMBoK
O Project Management Body of Knowledge (PMBoK, Corpo de Conhecimento em
Gerenciamento de Projeto) é um guia de boas práticas, desenvolvido, gerenciado e publicado
pelo Project Management Institute (PMI), que visa apresentar ferramentas úteis e relevantes
ao gerenciar projetos e que comumente apoiam um gerente de projetos durante o desempenho
de sua função, também descrito como “o ciclo de vida de gerenciamento de projetos e seus
respectivos processos” (PMI, 2013).
Um projeto é definido por ser um “esforço temporário empreendido para criar um
produto, serviço ou resultado exclusivo” (PMI, 2013). A versão cinco (05) do PMBoK (mais
atual, publicada em 2013) engloba dez (10) áreas de conhecimento em cinco (05) fases
(grupos de macroprocessos) para gerir projetos como um ciclo de vida.
2.2.1. Ciclo de Vida no Gerenciamento de Projetos
As áreas de conhecimento na gestão de projetos são:
I. Integração (Integration): identifica, define, combina, unifica e coordena
vários processos e atividades presentes nos grupos de processos de
gerenciamento de projetos;
II. Escopo (Scope): assegura que o projeto inclui todo o trabalho necessário, e
somente o necessário, para terminar o projeto com sucesso, definindo e
controlando o que está e não está incluso;
III. Tempo (Time): garante o término pontual do projeto;
IV. Custos (Costs): controla os custos para que o orçamento aprovado não seja
ultrapassado ao término do projeto;
V. Qualidade (Quality): determina as políticas de qualidade, objetivos e
responsabilidades para que o projeto satisfaça as necessidades pelas quais foi
empreendido;
VI. Recursos Humanos (Human Resources): organiza, gerencia e guia a equipe
do projeto;
VII. Comunicações (Communications): assegura que as informações do projeto
sejam planejadas, coletadas, criadas, distribuídas, armazenadas, armazenadas,

15
recuperadas, gerenciadas, controladas, monitoradas, e dispostas de maneira
oportuna e apropriada;
VIII. Riscos (Risks): planeja, identifica, analisa, responde e controla riscos para
aumentar a probabilidade de sucesso de um projeto;
IX. Aquisições (Procurements): compra ou adquire produtos, serviços ou
resultados externos à equipe do projeto, e gerencia contratos;
X. Partes interessadas (Stakeholders): identifica e desenvolve estratégias de
gestão para todas as pessoas, grupos ou organizações que podem impactar ou
serem impactadas pelo projeto com comunicação contínua, administração de
interesses e conflitos, e incentivo ao comprometimento das atividades do
projeto.
As fases do ciclo de vida de qualquer projeto cobrem:
I. Iniciação (Initiating): começo de um novo projeto, após a autorização de para
início;
II. Planejamento (Planning): plano que define o escopo do projeto, refina os
objetivos e alinha as ações necessárias para alcançar tais objetivos;
III. Execução (Executing): execução o trabalho definitivo no Plano de
Gerenciamento do Projeto (PGP) para satisfazer as especificações do projeto;
IV. Monitoramento e Controle (Monitoring and Controlling): acompanhamento
e análise do progresso e desempenho do projeto, identificando possíveis
necessidades de mudança no PGP;
V. Encerramento (Closing): conclusão de todas as atividades do projeto,
encerrando-o formalmente.
É possível visualizar abaixo a interação entre as áreas de conhecimento e o ciclo de
vida na gestão de projetos:

17
2.2.2. A Influência Cultural nas Estruturas Organizacionais em Projetos
A estrutura organizacional em um projeto possui extrema relevância em diversas áreas
do projeto, podendo impactar no seu sucesso ou fracasso, variando de acordo com o nível de
autoridade que o gerente do projeto tem condições de exercer dentro da hierarquia.
A estrutura organizacional é dividida em três tipos, sendo (1) Funcional, (2) Matricial,
e (3) Projetizada. Cada tipo de estrutura fornece condições variadas de poder ao gerente do
projeto sobre as características de comuns de projetos:
Fonte: PMI, 2013
A estrutura Projetizada apresenta melhores condições para ser a maior beneficente ao
desenvolvimento de projetos, pois em todas as características informadas, o gerente de
projetos possui altos níveis de poder e disponibilidade de recursos para planejar, executar,
monitorar e controlar projetos. Neste tipo de estrutura, a hierarquia da organização é
preenchida por gerentes de projeto com equipes focadas em tempo integral (conhecidas como
equipes dedicadas), exclusivamente voltados na execução de projetos.
Fonte: PMI, 2013

18
Na outra ponta da estrutura, encontra-se a Funcional que representa menores
condições de influenciar projetos, por limitar o poder e disponibilidade de recursos ao gerente
de projetos para desenvolvimento das atividades inerentes. Neste tipo de estrutura, a
hierarquia da organização é preenchida por gerentes funcionais (tendo também a
responsabilidade pela execução de projetos), onde os membros das equipes pertencem a áreas
funcionais, mas são emprestados (temporariamente alocados) para execução de projetos
(conhecidas como equipes de tempo parcial) – podendo desfalcar as equipes funcionais às
quais pertencem originalmente, dependendo do planejamento realizado pelo gerente do
projeto (que é também o gerente funcional).
Fonte: PMI, 2013
No meio termo, existe a estrutura Matricial buscando combinar as caraterísticas das
estruturas Projetizada e Funcional, onde os membros da equipe do projeto também são
originalmente de equipes funcionais. Esta estrutura é subdividida em três (03) partes: Fraca,
Balanceada, e Forte.
A estrutura Matricial Fraca assemelha-se muito às características da estrutura
Funcional, com a diferença de que o papel do gerente de projetos em si está mais vinculado à
figura de um assistente / facilitador, que visa auxiliar o andamento do projeto, apoiando a
equipe e coordenando as comunicações. Neste tipo de estrutura, o gerente do projeto não
possui autoridade para tomar ou executar decisões por conta própria (PMI, 2013).
Fonte: PMI, 2013

19
A estrutura Matricial Balanceada entende a necessidade da existência de um gerente
de projetos em meio à execução de um, mas o gerente do projeto está subordinado ao gerente
funcional – limitando sua autoridade que, normalmente, estende-se à tomada de algumas
decisões, mas com reporte e aprovação do gerente funcional.
Fonte: PMI, 2013
A estrutura Matricial Forte assemelha-se muito à estrutura Projetizada, pois contém
uma hierarquia paralela envolvendo somente gerentes de projetos, mas ainda contendo os
membros da equipe de projetos como sendo membros de uma funcional. O gerente do projeto
possui considerável autoridade na tomada de decisões, porém a equipe de projetos atua em
tempo integral.
Fonte: PMI, 2013

20
A estrutura Composta indica que a organização envolve todas as estruturas
apresentadas simultaneamente em diversos momentos. Uma organização baseada em estrutura
Funcional pode, temporariamente, alocar pessoas de um mesmo departamento (ou não) para
atuarem integralmente em um projeto específico onde, ao formaram-se uma equipe de projeto,
podem criar parcialmente na organização uma estrutura Projetizada dentro da estrutura
Funcional (padrão utilizado pela empresa deste exemplo). Outro fator que pode caracterizar
esta estrutura é a possibilidade de a organização ser baseada apenas na estrutura Matricial
Forte, mas permitir que pequenos projetos sejam executados pelos departamentos funcionais
(PMI, 2013).
Fonte: PMI, 2013
A composição de uma equipe, que varia entre dedicada (preferível em projetos) ou de
tempo parcial, pode existir em qualquer uma das estruturas apresentadas. Porém, é comum
que uma equipe dedicada exista com mais frequência em uma estrutura Projetizada, e equipes
de tempo parcial estejam mais frequentemente presentes em estruturas Funcionais e
Matriciais.
Quando a atividade de executar e gerenciar projetos torna-se uma prática empresarial,
é saudável que haja apoio para manter e melhorar a estrutura existente para tal. Em
atendimento a esta necessidade, surgiu o conceito de Escritório de Projetos (Project
Management Office, PMO).

21
Existem diversos tipos de Escritórios de Projetos. Dentre eles, o Project Support
Office (PSO) visa apoiar, técnica e administrativamente, os gerentes de projetos com
ferramentas e serviços para planejar, programar, conduzir mudanças e controlar custos
durante o ciclo de vida de um projeto (DINSMORE, 1999).
Dentre os tipos de Escritórios de Projetos existentes, entende-se que o PSO é o qual
possui menor influência na execução de projetos, pois somente visa apoia-los por meio de
“modelos, melhores práticas, treinamento, acesso a informações e lições aprendidas com
outros projetos” (PMI, 2013), e retrata uma estrutura menor, mas concisa, em comparação a
um Program Management Office (PrgMO), que visa a gestão de programas de projetos, ou
um Chief Project Officer (CPO), que foca em gerir portfólios de projetos.
A estrutura de uma organização clarifica suas intenções quanto às diversas aplicações
em projetos. A estrutura Projetizada indica maior propensão à aceitação e execução de
projetos em comparação à estrutura Funcional.
O PMBoK revela que organizações com maior nível de maturidade para gerenciar
projetos tendem a entrega-los com maior e melhor integração e coordenação, definição e
entrega dos requisitos acordados (envolvendo prazos, custos, e níveis de qualidade), controle
e organização de contratos, materiais e equipamentos, além de potencializar a motivação,
consciência, e comunicação da equipe (RAD; LEVIN, 2002):
Fonte: HARRISON, 2006

22
O nível de qualidade dos resultados frequentemente alcançados por uma consultoria
que gerencia projetos está intimamente ligado ao nível de maturidade para gerir projetos que a
mesma possui.
Existe uma correlação, elaborada por PRADO (2003), que ilustra uma tendência maior
no desvio (“XX”) de alcance das metas de um projeto para organizações com baixo nível de
maturidade em gerenciamento de projetos, enquanto esta tendência de desvio diminui (“X”)
na medida em que tal nível de maturidade aumenta:
2.3. Modelos de Maturidade na Gestão de Projetos
Apesar de apresentar dicas e competências técnicas para gerenciar projetos, o guia
PMBoK em si não apresenta um método de avaliação e estruturação do nível de maturidade
em processos de gestão de projetos utilizados nas empresas que os executam.
Suprindo esta demanda, foram surgindo modelos para avaliação de maturidade ao
longo dos anos, na medida em que a disciplina de gerenciamento de projetos foi sendo cada
vez mais desenvolvida e valorizada nas organizações que entenderam os benefícios e poderes
que projetos podem agregar às suas respectivas visões estratégicas de negócio de curto à
longo prazo.
2.3.1. CMM – Capability Maturity Model
O Capability Maturity Model (CMM) é o modelo para avaliação de maturidade mais
conhecido e utilizado. Basicamente, o CMM possui cinco (05) níveis de maturidade, sendo
desmembrado em (RABECHINI JR et al., 2005):

23
 Primeiro nível (inicial), que é caracterizado pela ausência de metodologia
para execução de projetos, ultrapassando prazos e custos originais;
 O segundo nível (repetível) constitui-se de conceitos básicos em gestão de
projetos, em que novos projetos cumprem os prazos acordados por serem
baseados em projetos similares anteriormente executados;
 Já no terceiro nível (definido) existe um padrão para processos de
gerenciamento de projetos utilizados na organização, processos estes que
fornecem a metodologia e procedimentos para execução de novos projetos;
 O quarto nível (gerenciado) indica que os processos e produtos utilizados
para executar projetos são quantitativamente controlados na organização;
 Por fim, o quinto e último nível (otimização) é marcado pela ramificação do
modelo de maturidade na organização, permitindo a elaboração de um
processo de melhoria contínua.
Fonte: RABECHINI JR; et. Al, 2005
O CMM também inspirou o desenvolvimento de outros modelos de avaliação de
maturidade, com destaque ao Project Management Maturity Model (PMMM), desenvolvido
por Kerzner em 2001.

24
2.3.2. PMMM – Project Management Maturity Model
Apesar de o PMMM ser um modelo criado com base no CMM, este contém diversas
diferenças em relação ao CMM. Mas, como algumas de suas similaridades, tal modelo
também possui cinco (05) níveis de maturidade:
 Nível 1 (Imaturidade): Linguagem comum – conhecimento básico.
 Nível 2 (Imaturidade): Processos comuns – processos definidos.
 Nível 3 (Maturidade): Metodologia singular – processos controlados.
 Nível 4 (Excelência): Benchmarking – processos gerenciados, buscando
melhoria contínua.
 Nível 5 (Excelência): Melhoria contínua – processos otimizados.
O nível 2 (Processos Comum) do PMMM possui um ciclo de vida genérico, que é
subdivido em cinco (05) fases:

25
 Nível 2.1: Embrionária – entendimento e reconhecimento de gestão de
projetos na empresa;
 Nível 2.2: Reconhecimento da Alta Direção – é avaliada por meio de:
 Visibilidade em suporte;
 Compreensão quanto ao gerenciamento de projetos;
 A existência de um patrocinador;
 Cultura flexível quanto a mudanças no modo de fazer negócios;
 Nível 2.3: Reconhecimento da Média Gerência – apoio e comprometimento
para cumprir prazos e disponibilizar recursos necessários aos projetos;
 Nível 2.4: Crescimento – desenvolvimento interno de uma metodologia para
gerir projetos e comprometimento às atividades de planejamento;
 Nível 2.5: Maturidade – elaboração de um sistema formal para controle
gerencial de custos e prazos, e o desenvolvimento de um programa de
aprendizado contínuo para elevação das competências internas em gestão de
projetos.
Devido à grande similaridade entre o CMM e o PMMM, podem existir conflitos caso
ambas sejam utilizadas, pois possuem diferenças peculiares. Mas, em geral, existe
cumplicidade entre essas terminologias, permitindo o alcance de resultados satisfatoriamente
destacáveis.
2.3.3. OPM3™ – Organizational Project Management Maturity Model
O Organizational Project Management Maturity Model (OPM3™) é outro modelo
para avaliação de maturidade em gestão de projetos. Tal modelo foi criado por meio de um
sistema voluntariado, envolvendo profissionais do mundo inteiro, com base em pesquisas,
análises e discussões de diversos outros modelos de maturidade, coordenado pelo PMI.
Seu grande diferencial está em analisar processos para gestão de projetos
organizacionais, que abrangem do nível do projeto em particular a programas e portfólios de
projetos (HARRISON, 2006) – observando-se, então, que sua aplicação é mais adequada em
organizações que já possuem o hábito de planejar e executar projetos de médio e grande porte.

26
O OPM3™ é partilhado em cinco (05) dimensões:
 Processos e metodologia;
 Recursos humanos;
 Apoio da alta administração;
 Capacidade de aprendizagem;
 Aderência do planejamento estratégico.
2.3.4. MMGP – Modelo de Maturidade em Gerenciamento de Projetos
O Modelo de Maturidade em Gerenciamento de Projetos (MMGP) é um modelo
desenvolvido por Darci Prado em 2002, atualizado em 2014 para a segunda (2ª) versão, que
visa avaliar o nível de maturidade na gestão de projetos que setores organizacionais possuem
(SILVA, 2014).
O MMGP é composto por cinco (05) níveis de maturidade: (1) Inicial, (2) Conhecido,
(3) Definido, (4) Gerenciado, e (5) Otimizado.

27
Fonte: PRADO, 2014
Este modelo possui seis fundamentos (dimensões) para cada um dos cinco níveis de
maturidade apresentados, envolvendo (1) conhecimento de gerenciamento, (2) uso prático de
metodologias, (3) informatização, (4) estrutura organizacional, (5) relacionamentos humanos,
e (6) alinhamento com os negócios da organização (HARRISON, 2006). Os níveis de
maturidade inter-relacionam-se às dimensões da seguinte maneira:
Fonte: PRADO, 2014
Recomenda-se que este modelo seja aplicado por setores / departamentos individuais,
para que seja avaliado o nível de maturidade segmentado por silos organizacionais, ao invés
da organização como um todo. A avaliação de maturidade por ser realizada por meio do site
http://www.maturityresearch.com, onde também é possível comparar os resultados com o
desempenho de outras organizações que atuem no mesmo segmento (benchmarking).

28
O MMGP destaca abaixo as principais características que as organizações comumente
possuem ao avançar por cada nível de maturidade presente neste modelo:
Fonte: PRADO, 2014
Um resumo elaborado por Prado (2003) evidencia as principais características de
organizações presentes em cada nível de maturidade do modelo MMGP:
Mesmo contrariando as boas práticas, é bastante comum as organizações utilizarem
mais de uma metodologia para autoavaliar o nível de maturidade em processos de
gerenciamento de projetos, devido à cada uma reter características próprias de avaliação de
maturidade, apesar do objetivo final ser o mesmo.

29
3. METODOLOGIA
Este estudo pretende verificar se a maturidade de uma Central de Serviços de TI
externa para implementar projetos de infraestrutura agrega mais valor ao negócio de seu
cliente em comparação a uma consultoria de projetos de TI, partindo da premissa que já existe
uma relação de confiança entre as organizações e conhecimento aprofundado nas rotinas
operacionais do cliente.
Por meio de uma pesquisa com base em revisão bibliográfica e comparativa, a
abordagem deste estudo incluirá os tópicos abaixo:
Primeiramente, a apresentação da metodologia ITIL (Information Technology
Infrastructure Library) em sua 3ª versão (mais recente), gerenciada e publicada em 2011 pela
OGC (Office of Government Commerce), que fornece as melhores práticas utilizadas para
guiar a gestão de processos e serviços, sendo a principal metodologia utilizada em Centrais de
Serviços de TI.
Logo em seguida, um breve entendimento do guia PMBoK (Project Management
Body of Knowledge) em sua 5ª edição, gerenciado e publicado em 2013 pelo PMI (Project
Management Institute), por ser fortemente utilizado em gestão de projetos.
Em um terceiro momento, é realizada a apresentação dos modelos para medição de
maturidade mais conhecidos em organizações que gerenciam projetos, tais como CMM
(Capability Maturity Model), PMMM (Project Management Maturity Model), OPM3™
(Organizational Project Management Maturity Model), e MMGP (Modelo de Maturidade em
Gerenciamento de Projetos).
Após a apresentação dos conceitos referidos, foi disponibilizado um plano genérico
para a elevação do nível de maturidade na gestão de projetos em uma Central de Serviços de
TI externa, por meio das práticas fornecidas no modelo MMGP (Modelo de Maturidade em
Gerenciamento de Projetos).

30
4. DISCUSSÃO DOS RESULTADOS
Os relatórios gerados a partir de análises baseadas no modelo MMGP de Prado levam
à conclusão de que o índice de sucesso total em um projeto é mais provável se o nível de
maturidade em projetos for maior, neste mesmo nível é comum à diminuição do índice médio
de atrasos e estouros nos custos acordados (SILVA, 2014).
Desta forma, foi percebido que a maturidade é o que define a capacidade cognitiva de
uma organização implantar projetos, e o que influencia, positiva ou negativamente nesta
capacidade, é sua estrutura organizacional, que é definida de acordo com a cultura da empresa
pelo corpo diretivo – que elabora, mantém e prolifera a estratégia do negócio.
Apesar de influenciar (e muito), a estrutura organizacional não determina o sucesso ou
fracasso de um projeto, dando-se, então, maior ênfase na responsabilidade que o nível de
maturidade influi no resultado de um projeto. Uma CSTI que é baseada em ITIL tem, em seus
processos tradicionais, o desempenho de melhoria contínua (por meio do Ciclo PDCA) no
ambiente de TI pelo qual é responsável, implicando à execução de pequenos projetos com
foco em otimização de processos e serviços, porém embasada na metodologia sugerida pelo
ciclo de vida da ITIL ao invés das dicas e processos disponibilizados pelo PMBoK.
É comum que uma Central de Serviços de TI (CSTI) esteja modelada em uma
estrutura Matricial, tendendo a gerenciar projetos com equipes de tempo parcial, enquanto
uma Consultoria de Projetos, por ser tradicionalmente modelada em uma estrutura
Projetizada, possui maior tendência a gerenciar projetos com equipes dedicadas (de tempo
integral) – sendo esta uma das principais vantagens oriundas dessa estrutura. Mas, variando de
acordo com o tipo de contrato realizado entre o gerente do projeto e seus recursos (membros
da equipe), tais membros podem atuar em mais de um projeto simultaneamente por possuírem
diversos clientes e demandas similares (algo bastante comum no cotidiano das organizações
atuais), tornando o método de atuação de uma Consultoria de Projetos mais próximo da
estrutura Matricial utilizada em uma CSTI, descartando tal vantagem.

31
Para adquirir maturidade na execução de projetos, uma organização precisa estruturar-
se seguindo alguns passos, e implementa-los com maior qualidade e eficiência a cada
execução. A implementação de um roteiro apropriado que possua uma análise detalhada das
capacidades de uma organização reduzirão significantemente o tempo necessário para
melhorar seu nível de maturidade (DEMIR; KOCABAS, 2010).
O MMGP de Prado foi o modelo de maturidade escolhido para o desenvolvimento de
um plano de ação genérico para uma Central de Serviços de TI externa (mas não limitando-se
somente a esta entidade) ter condições de elevar seu nível de maturidade na implementação de
projetos, e capacitando-a a uma competição corporativa saudável com Consultorias de
Projetos de TI, no que tange a benefícios como custos, qualidade e satisfação das partes
interessadas.
Tal modelo foi escolhido como base para a elaboração do plano de ação em evidência
pela simplicidade e efetividade de informações fundamentadas, (presentes no site
http://www.maturityresearch.com), onde é possível, inclusive, encontrar um questionário
consistente para mapear o nível de maturidade atual de um setor organizacional. Um dos
maiores benefícios existentes neste modelo é a realização anual de benchmarks, abrangendo
resultados de empresas nacionais e multinacionais no Brasil – também disponíveis no site
referido.
Prado (2003) propõe um plano de ação para que seja alcançado o nível 2 (dois) de
maturidade em gerenciamento de projetos pelo MMGP:
Adicionalmente, o plano de melhoria acima evidencia o desenvolvimento de um EGP
(Escritório de Gerenciamento de Projetos, PMO). Neste caso, um EGP de Suporte (PSO,
Project Support Office) é o mais indicado, pois objetiva apenas auxiliar o acesso às
informações inerentes, e apoio e treinamento sobre as melhores práticas para gestão de
projetos, não exercendo grande influência nas tomadas de decisão dos projetos.

32
O segundo plano de ação proposto por Prado (2003) busca elevar para o nível 3 (três)
a maturidade de um setor organizacional no modelo MMGP:
Apesar dos planos para evolução do nível de maturidade, ainda existe a necessidade de
apresentar ao cliente as novas camadas de prestação de serviços que a CSTI passa a oferecer,
comunicando-o que também está apta a implementar projetos, reforçando a qualidade já
conhecida na execução de tarefas cotidianas, além da confiança que já existe entre as
organizações – restando, apenas, participar e vencer processos seletivos (licitações) para
assumir a gerência de novos projetos.
Com base no conteúdo apresentado neste artigo, acredita-se que a capacidade de uma
mesma organização (CSTI) que suporta todo o ambiente operacional de infraestrutura de TI
obter o conhecimento, a disciplina e os recursos necessários para implementar projetos neste
mesmo ambiente pode gerar diversos benefícios e dirimir quaisquer possíveis problemas
durante e após a execução de projetos, devido à minimização de processos burocráticos e
barreiras hierárquicas – provando a hipótese contextualizada em que uma CSTI possui
condições de implementar projetos com eficiência similar apresentada por consultorias
especializadas.
Porém, existe a necessidade de reestruturar a CSTI para que esta conquiste tal
competência, a começar pela elevação do nível de maturidade em gerenciamento de projetos,
que envolve cultura e estrutura organizacional, capacitação e metodologia, informatização, e
alinhamento com os objetivos estratégicos do negócio do provedor (CSTI).

33
5. CONSIDERAÇÕES FINAIS
Este estudo demonstrou que o método com maior resultado na busca pelo alcance da
criação e/ou elevação do nível de maturidade de uma Central de Serviços de TI (CSTI) para
gerenciar e implementar projetos se dá por meio de um modelo de medição de maturidade
estruturado e reconhecido. Todavia, cada um dos modelos de maturidade existentes não
cobrem todas as áreas predominantes no universo de gerenciamento de projetos, abrindo
possibilidades para que novos modelos sejam desenvolvidos.
Infelizmente, um único modelo não é suficiente para especificar em caráter definitivo
o nível de maturidade atual de uma organização, o que gera a necessidade de utilizar outros
modelos confiáveis para comparação, visando um denominador comum – enquanto a solução
alternativa mais adotada no mundo corporativo é o uso de, ao menos, dois modelos de
maturidade que se complementem e gerem resultados mais assertivos, permitindo análises
mais profundas para tomar decisões estrategicamente direcionadas ao aumento da vantagem
competitiva e liderança no segmento de atuação (Market Share) em que a organização que os
utiliza se mantém.
A revisão bibliográfica realizada evidenciou que existem diversos níveis de
maturidade para gerir projetos, dos mais rasos ou quase inexistentes até os mais altos,
indicando que toda e qualquer organização que deseje gerir e implementar projetos possa
fazê-los, divergindo, entretanto, na qualidade da entrega do produto ou serviço proposto, por
ser totalmente dependente do estado atual de conhecimento acumulado (maturidade) que a
organização possui para gerenciar projetos, tornando-os aderentes às expectativas das partes
interessadas (um dos objetivos principais) em maior ou menor grau.
Por meio deste estudo, foi indicado que uma CSTI pode gerenciar projetos com
eficiência similar à de uma consultoria especializada, variando, porém, de acordo com a
estrutura organizacional e, principalmente, nível de maturidade. O nível de maturidade deve
ser constantemente medido e elevado, por meio dos planos de ação expostos neste artigo, para
que a competitividade entre as organizações mantenha-se equivalente.
Em um futuro próximo é indicado a realização de um estudo de caso em uma CSTI
que proponha-se a executar projetos em conformidade às práticas disponíveis no guia PMBoK
para avaliação do nível de maturidade na gestão de projetos dentro do modelo MMGP,
disposto gratuitamente em http://www.maturityresearch.com, e aplicação dos planos de ação
descritos anteriormente.

34
6. REFERÊNCIAS BIBLIOGRÁFICAS
CARVALHO, M. M.; RABECHINI JR., R; PESSÔA, M. S. P.; LAURINDO, F. J. B.
Equivalência e completeza: análise de dois modelos de maturidade em gestão de
projetos. R.Adm., São Paulo, v.40, n.3, p.289-300, jul./ago./set. 2005.
CARVALHO, M. M.; RABECHINI JR., R; LAURINDO, F. J. B. Fatores críticos
para implementação de gerenciamento por projetos: o caso de uma organização de
pesquisa. Revista Produção v. 12 n. 2. São Paulo, 2002.
DEMIR C.; KOCABAS¸ I. Project Management Maturity Model (PMMM) in
Educational Organizations. Procedia Social and Behavioral Sciences 9, 2010.
HARRISON, P. D. Análise e resultados da aplicação de modelos de maturidade
em gerenciamento de projetos em uma organização: um estudo de caso. 2006, 216 f.
Dissertação (Mestrado) – Departamento de Engenharia Naval e Oceânica, Escola Politécnica,
Universidade de São Paulo, 2006.
Lifecycle Phases. Disponível em: <http://greenpages.com/traditional-it/it-consulting-
services/itil/>. Acesso em: 15 Agosto 2016.
OGC. ITIL V3 – Service Strategy. 2011.
PRADO, D. Fundamentos do Modelo Prado-MMGP. 2014.
PRADO, D. MMGP: UM MODELO BRASILEIRO DE MATURIDADE EM
GERENCIAMENTO DE PROEJTOS. 2014.
PMI, Inc. UM GUIA DO CONHECIMENTO EM GERENCIAMENTO DE
PROJETOS. (GUIA PMBOK®) — Quinta Edição, 2013.
RODRIGUES, V.B. GESTÃO DE QUALIDADE EM GERENCIAMENTO DE
SERVIÇOS DE TI: AVALIAÇÃO DO NÍVEL DE MATURIDADE DAS MELHORES
PRÁTICAS (ITIL). Universidade Nove de Julho. São Paulo, 2010.
RABECHINI JR., R; PESSÔA, M. S. P. Um modelo estruturado de competências e
maturidade em gerenciamento de projetos. Revista Produção, v. 15, n. 1, p. 034-043,
Jan./Abr. 2005.
SANTOS, G.S. GERENCIAMENTO DE PROJETOS EM TI: UM ESTUDO DE
CASO DO PLANO DE TRANSIÇÃO DE SERVIÇOS. Universidade Federal de Santa
Catarina - UFSC. Revista Produção, Santa Catarina, 2009.

Artigo - CSTI com Maturidade em Projetos

Mais conteúdo relacionado

Mais procurados

Destaque

Semelhante a Artigo - CSTI com Maturidade em Projetos

Artigo - CSTI com Maturidade em Projetos