O PMO (Escritório de Gestão de Projetos) da AtekPC

Prévia do material em texto

313-P02 
 1 1 D E O U T U B R O D E 2 0 0 7 
 
________________________________________________________________________________________________________________ 
 
Caso LACC # 313-P02 é a versão traduzida para Português do caso # 308-049 da HBS. Os casos da HBS são desenvolvidos somente como base 
para discussões em classe. Casos não devem servir como aprovação, fonte primária de dados ou informação, ou como ilustração de um 
gerenciamento eficaz ou ineficaz. 
 
Copyright 2013 President and Fellows of Harvard College. Nenhuma parte desta publicação pode ser reproduzida, armazenada em um sistema 
de dados, usada em uma tabela de dados, ou transmitida de qualquer forma ou por qualquer meio - eletrônico, mecânico, fotocopiada, gravada, 
ou qualquer outra - sem a permissão da Harvard Business School. 
F . W A R R E N M C F A R L A N 
J O H N H U P P 
M A R K K E L L 
O PMO (Escritório de Gestão de Projetos) da 
AtekPC 
 
Tinha começado a chover no começo da noite de 3 de março de 2007 e as ruas de Metrópolis, 
onde se localizava a sede da AtekPC, estavam frias e cinzas. Enquanto John Strider, CIO da AtekPC, 
fechava sua pasta ao final do dia, seus pensamentos se voltaram para o novo Escritório de Gestão de 
Projetos (do inglês Project Management Office - PMO) que ele havia aprovado vários meses antes. 
Durante os mais de 20 anos de sua gestão na AtekPC, Strider nunca tinha testemunhado o tipo de 
pressão que o setor de computadores pessoais (Personal Computer - PC) vinha enfrentando. Strider 
reconhecia que o setor estava em transição e que a sua Tecnologia da Informação estaria envolvida 
em alguns projetos críticos e importantes, enquanto a AtekPC procurava tomar a liderança nestas 
mudanças. Era esse pensamento que trazia à mente a iniciativa PMO. Se fosse implementado 
corretamente, este PMO poderia ser de grande ajuda para a AtekPC, mas Strider preocupava-se com 
o que poderia acontecer se pressionassem demais nesse sentido. Ao invés de ajudar, poderia tornar-se 
outro item na sua crescente lista de problemas. Havia muitas questões na sua cabeça com relação a 
isso: 
Quanto de GP é suficiente? Quanto apoio do PMO é suficiente? Quando se chega ao ponto 
no qual a estrutura e o processo do PMO trazem produtividade e contribuem para um 
resultado mais bem sucedido, com menos erros e de qualidade mais alta – qualquer que seja a 
sua definição de sucesso no começo? E quando é que o uso de GP se torna um fim em si 
mesmo? Quando é que você passa do limite? 
Strider achava que entendia o benefício deste PMO para a AtekPC, mas a iniciativa ainda estava 
no começo, precisava de tempo para dar provas de sua eficiência. Por um lado, a sua equipe gerencial 
tinha contratado algumas pessoas experientes e talentosas para tocar a iniciativa PMO. Por outro 
lado, eram novos no negócio de PCs e na AtekPC não entendiam o quão poderosa era a cultura da 
empresa, pensou ele. Como dizia Strider, o PMO tinha de se tornar parte da cultura da AtekPC e isso 
requeria pequenas mudanças durante um bom período de tempo. Se o PMO brigasse com a cultura, 
ele definitivamente fracassaria. Como CIO, estava consciente das muitas iniciativas e 
responsabilidade que tinha de cobrir com seus limitados recursos e sabia que o PMO era uma dessas 
iniciativas. Ele não podia se dedicar somente à construção deste novo PMO. Tudo tinha de ser feito 
em conjunto. Strider sabia da frustração do pessoal dele que estava trabalhando no PMO por não 
poder ir mais rápido. E ele também estava tentado a pensar em destinar rapidamente mais recursos 
para o PMO e nocautear projetos. Mas em sua opinião, isso seria uma iniciativa de vida curta – muita 
coisa, muito cedo, muito rápido. 
This document is authorized for use only in 2014-04-23 by Estacio_SC1 at Estacio de Sa University from April 2014 
to October 2014.
313-P02 O Escritório de Projeto da AtekPC 
2 
Strider fechou a pasta e dirigiu-se ao o elevador. Sua equipe gerencial sênior de TI estava com ele 
há muitos anos. Ele acreditava que podia liderá-los no caminho certo sem derrubar o seu entusiasmo 
por este novo PMO. Mas isso seria suficiente? Para Strider o retorno tinha a ver com alinhamento – 
alinhar direções estratégicas de negócio com recursos de TI e essa era a essência do PMO. Havia 
pouca margem para erros na AtekPC nestes tempos de mudanças. 
Histórico do Setor 
O setor de PCs experimentava uma tremenda pressão dos custos e passava por um período de 
consolidação. À medida que as margens de lucro caiam, os fabricantes de PCs lançavam estratégias 
de redução de custos que buscavam melhorar a eficiência de suas cadeias de suprimentos, enquanto 
baixavam o custo de distribuição. De acordo com um artigo recente de jornal: 
Os últimos resultados financeiros dos fabricantes de PCs mostram uma desaceleração nas 
vendas e lucratividade. Corporações e consumidores estão mantendo seus PCs por um período 
mais longo de tempo para evitar o custo e os distúrbios associados à atualização de seus 
equipamentos. Como resultado, compras estão sendo prorrogadas e fabricantes de PCs estão 
olhando novos mercados para oportunidades de crescimento. O setor parece estar passando 
por uma onda de consolidação à medida que o controle de custos e escala se tornam mais 
importantes do que nunca. 
Em 2007, uma grande revista de notícias publicou um artigo de capa intitulado “Os rumos do 
PC?” As ameaças reportadas na análise eram mundiais e vinham de uma variedade de fatores 
incluindo a crescente popularidade dos telefones móveis, PDAs e software de aplicativos baseados na 
Web. 
Para a maioria das pessoas, o email é o mais importante aplicativo que usam. Por um longo 
tempo, para enviar e receber emails era preciso ter um PC completo. Hoje em dia, entretanto, 
empresários e consumidores se beneficiam ao acessarem emails de qualquer lugar 24 horas por 
dia, 7 dias por semana, sem a inconveniência de carregar consigo um notebook. Atualmente, 
telefones móveis e PDAs oferecem essa funcionalidade, levando muitas pessoas a questionar a 
necessidade de ter um computador completo. O mercado era irrestrito nos tempos áureos do 
PC, mas o crescimento diminuiu consideravelmente. Ainda mais, com a crescente 
popularidade de aplicativos baseadas na web, empresas e consumidores estão comprando 
máquinas mais baratas que podem acessar e rodar aplicativos baseados na web e não 
requerem muito poder de processamento local ou armazenamento. Tendo ignorado a 
realidade por anos, os fabricantes de PCs finalmente estão fazendo alguma coisa. Para cortar 
custos, estão rearranjando suas operações por meio do uso da tecnologia da informação e 
observando novos produtos e novos mercados para manter o crescimento da receita e 
aumentar a rentabilidade. 
A AtekPC 
Fundada em 1984, a AtekPC cresceu e tornou-se um fabricante de tamanho médio de PCs nos 
EUA, com vendas de $1,9 bilhões em 2006. Empregava 2.100 trabalhadores em tempo integral e 
outros 200 trabalhadores em tempo parcial. Apesar de sua história de rápido crescimento nos anos 
1990, a AtekPC lutava em conjunto com outros fabricantes de PCs do mundo enquanto lidavam com 
a transição de um setor em crescimento para um setor maduro. Strider explicou: 
O setor de PCs mudou e continuará a mudar num ritmo acelerado. Num dado momento, o 
setor de PC alcançou altas taxas de crescimento e boas margens de lucro. Como resultado, 
This document is authorized for use only in 2014-04-23 by Estacio_SC1 at Estacio de Sa University from April 2014 
to October 2014.
O Escritório de Projeto da AtekPC 313-P02 
3 
tendemos a não ser tão cuidadosos quanto deveríamos no controle de custos e ao lidar com 
ameaças competitivas. Agora, é claro, a realidade mudou e estamos encarando uma crescente 
competição dos fabricantes asiáticos de PCs, que fizeram a transição de fabricantes contratados 
para vendedoresde suas próprias marcas de PCs. 
O setor de PCs está passando por uma certa consolidação com grandes players adquirindo 
players menores para conseguir maior escala. Portanto, este é hoje o cenário do nosso setor. 
Temos uma necessidade maior que nunca em sermos agressivos e nos movermos rapidamente 
para poder reduzir custos e conquistar novos mercados. Precisamos nos tornar uma 
companhia muito mais ágil para que nossas competências sejam mais consistentes com o que 
nosso nome implica. No futuro, teremos de ser muito mais sábios em termos de uso de TI ou 
arriscaremos nos tornar não lucrativos ou alvo de aquisições hostis.” 
No outono de 2006, a AtekPC já tinha começado várias iniciativas com o objetivo de posicionar a 
organização para o futuro. Uma dessas iniciativas era o estabelecimento de um Strategic Planning 
Office, cuja responsabilidade era propor mudanças de negócios. Sob os auspícios do Strategic 
Planning Office, o esforço inicial de PMO, que era focado em projetos de TI, se tornaria um dia um 
PMO corporativo. A AtekPC reconhecia que teria de ser capaz de gerenciar projetos mais eficaz e 
efetivamente para que as propostas do Planning Office tivessem sucesso. Em março de 2007, o 
Strategic Planning Office e o PMO inicial estavam em operação há alguns meses. De acordo com 
Strider, a AtekPC enfrentava intensa competição de preços e a gestão da empresa sofria forte pressão 
para assegurar que cada ação tivesse um retorno visível. 
A Tecnologia da Informação na AtekPC 
Ao longo dos anos a AtekPC desenvolveu um extenso portfólio de aplicativos. Estes aplicativos 
eram principalmente focados no nível operacional das funções de negócio típicas de um fabricante de 
PC, tais como contabilidade, suprimentos, manufatura, vendas e distribuição. A integração da 
arquitetura destes sistemas de aplicativos era apenas moderada, tanto que em 2007, as áreas 
funcionais normalmente recebiam informações com pouca integração multifuncional. Projetos de 
sistema de informação eram tipicamente esforços operacionais ou de manutenção feitos através da 
solicitação de uma determinada área funcional. Eram geralmente projetos de pequenos a médios em 
termos de tamanho e duração, e gerenciados informalmente sem práticas padronizadas. Como 
explicou o Diretor de Desenvolvimento de Aplicativos, Richard Steinberg: 
Nós sempre fizemos do nosso jeito. Tínhamos muitos projetos operacionais acontecendo e 
muitas melhorias em andamento, mas muito poucos aplicativos em andamento... Ao longo dos 
anos, havia certas pessoas na empresa que reconheciam que a qualidade do trabalho que 
fazíamos nos projetos poderia ser melhorada. Quando começamos a dar uma olhada no que 
precisávamos fazer no futuro, percebemos que tínhamos de realmente aprimorar nossas 
habilidades para sermos capazes de nos mover mais agressivamente e de lidar com múltiplos 
projetos de uma vez. Para tanto, montei o plano de um PMO, essencialmente uma metodologia 
de gerenciamento de projetos para todas as minhas áreas. 
O ambiente de mudança que a AtekPC enfrentava criava vários desafios que se planejava encarar 
com projetos grandes e complexos. O novo PMO estava sendo introduzido para prover a 
padronização para gerir estes projetos e promover melhorias no planejamento e desempenho das 
iniciativas. Apesar de a AtekPC ter feito alguns projetos grandes no passado, nos quais se 
empregavam algumas práticas formais, estes projetos não resultaram numa formalização duradoura 
das práticas. Steinberg explicou: 
This document is authorized for use only in 2014-04-23 by Estacio_SC1 at Estacio de Sa University from April 2014 
to October 2014.
313-P02 O Escritório de Projeto da AtekPC 
4 
Você pode retroceder alguns anos, ao Y2K, para a conversão de nosso sistema de gestão de 
pedidos; nesses grandes projetos usaram uma abordagem de gerenciamento de projeto. Não se 
deram conta disso. Juntou-se todo mundo, falou-se sobre quanto tempo levaria para fazer isso 
e eles fizeram. Todos receberam prêmios e disseram, “Foi tudo muito bem feito. Agora que 
acabou, temos de voltar a fazer projetos normalmente”. Não se percebeu que esta é a maneira 
de se fazer. De repente quando aquelas coisas grandes terminaram, quando desapareceram, 
então se voltou a tentar fazer coisas tiradas da cartola novamente. 
Em 2007, os projetos de TI eram normalmente gerenciados através da adição de responsabilidade 
de GP a uma das pessoas de desenvolvimento, que eram alocadas para áreas funcionais específicas. 
Por exemplo, o Analista Líder alocado para manufatura também desempenhava o papel de gerente 
de projeto. Analistas Líderes supervisionavam grupos de trabalho de analistas e programadores de 
diferentes níveis de conhecimento, e eram responsáveis por satisfazer os requisitos das áreas 
funcionais assim como o desempenho de seus grupos de trabalho. Usando um processo informal de 
iniciação, usuários requisitavam serviços de TI através do Analista Líder, que então gerenciava o 
projeto com apoio de recursos dentro do seu grupo de trabalho. O gerente, neste caso o Gerente de 
Sistemas de Manufatura, resolvia quaisquer pontos e conflitos, se necessário; caso contrário, a 
solicitação era recebida, executada e entregue através do Analista Líder. Métodos, documentação, 
práticas e ferramentas de projeto eram individualizadas pelo Analista Líder com pouca ou nenhuma 
consistência entre grupos de TI ou áreas de negócio. 
A AtekPC percebia muitos benefícios nesta abordagem informal de projetos. Os Analistas Líderes 
frequentemente estavam há muito tempo em suas áreas e conheciam profundamente as atividades do 
negócio, necessidades e pessoas. Como resultado de suas abordagens informais, respondiam 
rapidamente às solicitações dos usuários e eram capazes de balancear necessidades críticas 
emergenciais dentro de seus grupos de trabalho, com poucos conflitos. Por causa do histórico de 
entrega rápida, havia considerável confiança desenvolvida entre a área funcional e seus Analistas 
Líderes. A relação de confiança era muito personalizada e lealdades surgiam de ambos os lados. A 
abertura destas relações permitia ao Analista Líder juntar e avaliar rapidamente os requisitos e 
chegar ao consenso sobre um cronograma e data de entrega. Linda Star, uma Analista Líder da 
Manufatura, descreveu seu trabalho neste papel: 
No meu mundo tenho uma variedade de usuários com quem converso. Eles dizem, 
“Preciso disso.” Alguns dizem, “Realmente preciso disso. É possível? Isto é uma emergência e 
preciso disso”. Eu volto, olho no que o meu pessoal está trabalhando e digo “preciso que você 
acelere. Preciso que você me dê duas horas, dois dias, ou o quanto for preciso. Precisamos 
terminar essa coisa”... Faço um cronograma baseado no que cada um do meu grupo está 
fazendo e o que concluo depois de conversar com eles. 
Esta abordagem informal de gerenciamento de projetos foi tradicionalmente a norma na AtekPC. 
Historicamente, a visão prevalecente era que a TI era periférica às atividades base de negócio na 
AtekPC. Como resultado, a TI era vista como uma tomadora de pedidos, da qual se esperava a 
prestação de serviços sob demanda. Na década anterior, os projetos tornaram-se cada vez mais 
focados em operações e manutenção, num esforço para melhorar eficiências dentro das funções de 
negócios. O desenvolvimento de sistemas de integração multifuncional e o uso de tecnologias de 
internet foram somente duas das muitas necessidades emergentes enquanto a AtekPC lutava com 
mudanças radicais no seu setor e mercado. Os projetos novos requeridos eram maiores, mais 
complexos e envolviam múltiplas áreas funcionais e múltiplas áreas tecnológicas, em contraste com 
os projetos altamente focados, realizados no passado por um grupo de trabalho único. As demandas 
destas novas iniciativas e os projetos sobrecarregavam os métodos informais de gestão de projetos. O 
PMO AtekPC estava sendo implementadopara garantir práticas melhores e mais consistentes para 
This document is authorized for use only in 2014-04-23 by Estacio_SC1 at Estacio de Sa University from April 2014 
to October 2014.
O Escritório de Projeto da AtekPC 313-P02 
5 
projetos de negócio de TI. Entretanto, implementar um PMO na AtekPC era, em si mesmo, um 
desafio que requeria uma habilidosa gestão para ter sucesso. Um equilíbrio difícil tinha de ser 
mantido entre manutenção e novos desenvolvimentos, assim como entre recursos destinados a 
atividades de desenvolvimento versus recursos que iam para atividades de gerenciamento de projeto 
sob o novo PMO. Strider descreveu o desafio: 
Não temos tudo definido. Isso é melhor que pensar que temos e não ter. No departamento 
de TI temos de ser mais capazes de gerir os conflitos entre novas iniciativas críticas de negócio 
e operações com mudanças adicionais aos sistemas existentes. Não podemos sacrificar um pelo 
outro. A questão é que fazíamos somente manutenção operacional e agora precisamos ter uma 
cultura de fazer ambos. 
Missão do PMO 
A missão do PMO da AtekPC tinha evoluído gradualmente desde seu início no final de 2006. Na 
primavera de 2007, não havia um consenso completo em relação a seu propósito, suas 
responsabilidades e sua autoridade. Apesar de não existirem planos e documentação formal para o 
PMO, a meta imediata era estabelecer o escritório e provar o seu valor. O consenso geral era que o 
propósito do PMO era conseguir benefícios derivados de práticas consistentes de projetos. Apesar de 
não estarem claramente especificados ou serem mensuráveis nesse momento, estes benefícios eram 
expressos em uma variedade de termos incluindo melhorias de TI no desempenho dos projetos e 
utilização de recursos, a melhorias corporativas na gestão de custos e competência corporativa para 
lançar produtos. Steinberg explicou segundo a perspectiva empresarial: 
Se penso sobre o setor de PC e seus desafios, penso em duas coisas que poderiam ser 
motivadoras para um PMO. Uma poderia ser a redução de custos. Não podemos ser 
descuidados. Francamente, temos de ser muito mais cuidadosos ao usar nossos recursos. Outra 
motivação para melhorarmos nossos projetos e sermos mais criativos, adaptáveis e ágeis em 
lançar novos produtos. E para lançar novos produtos, o que você diria que está impulsionando 
estas iniciativas, senão o gerenciamento de projetos? 
Contudo, as responsabilidades do PMO não eram assim tão claras. Naquele momento, as 
responsabilidades do PMO estavam limitadas a projetos de TI, apesar das discussões sobre expandir 
seu escopo para um PMO em nível corporativo que incluiria projetos de negócio no futuro. As tarefas 
específicas de um PMO eram tipicamente divididas em duas categorias: focado em projeto e 
orientado para a corporação. As responsabilidades com foco em projeto tais como consultoria, 
aconselhamento (do inglês mentoring, quando um profissional mais velho e experimente orienta os 
mais jovens) e treinamento eram serviços que capacitavam o sucesso individual dos projetos. Por 
outro lado, as responsabilidades corporativas tratavam de serviços que poderiam melhorar todos os 
projetos tais como gestão de portfólio, padrões de GP, métodos e ferramentas, e desempenho do 
projeto. A definição das responsabilidades do PMO estava em constante evolução enquanto a AtekPC 
tentava ganhar apoio e conseguir definir a sua missão e charter: 
Na AtekPC, as responsabilidades focadas em projeto eram os principais meios usados para provar 
os méritos de seu PMO. O plano era criar aceitação por meio de consultoria e aconselhamento sobre 
projetos individuais. Mark Nelson, o novo Gerente de PMO, falou sobre este esforço: 
O que venho fazendo desde outubro de 2006 tem sido aconselhamento e suporte de 
gerenciamento para projetos importantes que foram identificados pelos executivos da TI. Para 
o futuro imediato, até que as coisas estejam funcionando, o plano é que eu trabalhe com uma 
pessoa no planejamento do projeto – reuniões regulares com as equipes, relatórios de posição, 
questões de manutenção e gestão de riscos. 
This document is authorized for use only in 2014-04-23 by Estacio_SC1 at Estacio de Sa University from April 2014 
to October 2014.
313-P02 O Escritório de Projeto da AtekPC 
6 
Para esse fim, o PMO continuou a obter suporte das áreas funcionais e do pessoal de TI 
envolvidos nos projetos. Uma das maiores limitações era a escassez de pessoal especializado em PMO 
disponível para ajudar nestes projetos. Além de Nelson, havia outros três gerentes de projeto 
alocados ao PMO e estes eram empregados contratados. Usar pessoal de PMO para gerenciar projetos 
diretamente acontecia raramente; entretanto, Nelson tinha alocado um de seus gerentes de projeto 
para um projeto crítico envolvendo o lançamento de um novo computador notebook. 
A AtekPC não priorizava o desenvolvimento de pessoal com postura empresarial para o PMO. O 
novo PMO desenvolvera alguns processos e procedimentos padrão de projetos. Steven Gardner, 
Manufacturing Systems Manager, comentou sobre um processo de charter de projeto que o PMO 
tinha introduzido: 
Nelson nos ajudou a desenvolver o que chamamos de “formatação da ideia”, onde 
tentamos eliminar muitas chamadas aleatórias que nos chegam. Estamos tentando priorizar 
melhor o que trabalhamos e usar esta “formatação da ideia” nos leva a entender o negócio a 
partir de qualquer ideia que surja. Isto nos força a pensar tanto pelo lado do nosso ponto de 
visto como pelo do solicitador. Ajuda-os a pensar sobre uso e tudo mais. Por que vamos 
conseguir economizar? Qual é a razão para fazer isso? Vale a pena fazer este projeto à custa de 
outro? E agora, como faço para priorizar? Portanto, está nos ajudando a nos aproximarmos 
daquilo em que estamos trabalhando. 
Os serviços com foco corporativo desenvolvidos pela equipe de PMO do Nelson foram bem 
aceitos. Apesar do progresso nesta área estar restringido devido aos recursos limitados, havia um 
claro entendimento mesmo pelo CIO de que o PMO era responsável por definir, publicar e 
disseminar práticas de projeto, padrões e ferramentas. Por outro lado, gestão de portfólio (a mudança 
de gerenciar um projeto para a definição de técnicas para gerenciar um fluxo contínuo de projeto) e 
responsabilidades por arquivamentos (a definição de registros de projetos para compartilhamento do 
conhecimento) não estavam sendo tratadas. Nelson esperava ser capaz de incluir estas obrigações na 
missão quando o PMO se desenvolvesse, mas sem recursos adicionais não era factível no curto prazo. 
Ele também percebeu que só disporiam de recursos adicionais se tirassem de outras 
responsabilidades críticas e isto poderia comprometer sua capacidade de manter a eficácia 
operacional. Conseguir esse equilíbrio era desafiador. 
A última área de preocupação em relação à missão do PMO era a questão da autoridade. Strider 
reconhecia que a fiscalização destas novas práticas de projeto requeria autoridade formal e estava 
preparado para concedê-la somente quando o PMO fosse aprovado pelas áreas de negócio e de TI. 
Nos esforços iniciais de desenvolvimento, Nelson tinha a vantagem de trabalhar com uma autoridade 
implícita vinda da percepção geral de mudança no direcionamento gerencial. Entretanto, o PMO 
também tinha o apoio do VP sênior, Larry Field, Diretor do Grupo de Suporte de Gerenciamento de 
Projetos e peça chave da iniciativa PMO desde o seu início. Ele explicou: “Para sermos efetivos, temos 
de ter apoio de cima. E temos apoio da vice-presidência através de John Strider e daí para baixo. Essa 
é a primeira e a mais crítica coisa a se fazer para isso funcionar”. 
Entretanto, como nem todos os executivos seniores estavam igualmente entusiasmados com o 
conceito PMO, a autoridade estava principalmente sendo exercida de baixo para cima conforme o 
valor dos serviços do PMO. Mesmo isso era limitadoàquelas áreas funcionais e às de TI ativamente 
engajadas no PMO. Não havia nenhum plano concreto para fiscalizar o uso em nível corporativo. 
Nelson resumiu esta abordagem com esta colocação: 
Na realidade, o aconselhamento é o que concretamente está gerenciando os projetos. Por 
ora estamos sendo pacientes para podermos conseguir alguns exemplos concretos para lhes 
mostrar. Podemos dizer “veja o que isto está fazendo para você. Este projeto que estimamos 
This document is authorized for use only in 2014-04-23 by Estacio_SC1 at Estacio de Sa University from April 2014 
to October 2014.
O Escritório de Projeto da AtekPC 313-P02 
7 
levar um ano e meio, estamos conseguindo fazer em três ou quatro meses porque colocamos 
estas práticas para funcionar.” E isso é a chave porque nos permite mostrar nosso valor. Esta 
tem de ser a abordagem por enquanto. 
A Organização PMO 
Estavam sendo considerados dois modelos organizacionais para o PMO o PMO-heavy e PMO-
light, que representavam dois extremos de um espectro de abordagens organizacionais de PMO. Em 
um extremo, o PMO-heavy compreendia uma equipe completa de gerentes de projeto que assumiam 
a responsabilidade pela gestão do todo. Este modelo focava na aquisição de especialistas de gestão de 
projetos sob a direção do PMO. Na versão extrema do PMO-heavy, nenhum projeto operava fora da 
gestão e controle direto do PMO. No outro extremo do espectro, o PMO-light era caracterizado pela 
equipe mínima de especialistas que trabalhavam com gerentes de projeto internos para realizar as 
responsabilidades do PMO. Este modelo focava no desenvolvimento de habilidades nos gerentes de 
projeto internos que não estavam formalmente conectados com o PMO. Na versão extrema do PMO-
light, todos os projetos operavam fora do PMO e submetidos aos controles organizacionais existentes, 
e os donos dos projetos eram a área funcional e do grupo de TI encarregado da execução do projeto. 
A definição do PMO, no espectro entre PMO-heavy e PMO-light, estava gerando muita discussão e 
pouco entendimento. Strider pronunciou-se sobre esta controvérsia: 
Exatamente agora temos quatro pessoas em tempo integral... Dada a velocidade na qual 
nós, como empresa, queremos nos mover – e nós como uma indústria precisamos nos mover – 
acho que quatro pessoas permanentes é muito pouco. Vejo essas pessoas alocadas a grandes 
projetos para ajudar, mas a diversidade de aplicativos é muito grande. Não vejo toda a gestão 
movendo-se para este grupo. Existe uma diferença de opinião entre mim e o PMO neste ponto. 
Temos de encontrar um meio termo... estou suficientemente convencido de que deveria ser 
light. Isso não significa que não me questione, porque há muitas pessoas neste departamento 
que estão constantemente me desafiando em relação a isso. O que é bom, quer dizer, nunca 
quis um bando de cordeirinhos ao meu redor. 
Apesar da concordância de Nelson em trabalhar com uma equipe pequena no início, ele sentia que 
atrasos poderiam comprometer a capacidade deles em prestar os serviços de PMO e em demonstrar 
seu benefício para as áreas funcionais do negócio. Entretanto, ele e outros gerentes reconheciam que 
os recursos não eram de graça e tinham de vir de algum lugar, o que significava sacrificar as 
atividades de uma pessoa para avançar usar em outra atividade. Strider enfrentava esse desafio e os 
quatro recursos atuais do PMO foram conseguidos à custa de outras equipes operacionais. Mesmo 
quando Nelson trabalhava dentro destes limites, esperava conseguir mais ajuda. E Nelson explicou: 
Se não houvesse nenhuma restrição, gostaria de ter montado a equipe muito rapidamente 
com analistas de projeto e com gerentes. Juntar um grupo de pessoas no começo. A maioria 
deles poderia ser de novatos no início. A partir daí, à medida que se caminha, você poderia 
trazer o restante da organização. Todos seriam parte do PMO. Portanto teríamos graus 
variados de experiência, desde GPs seniores até pessoas juniores. Conseguiríamos muita coisa 
somente com esse passo. 
Steinberg preocupava-se com os recursos requeridos e qual a percepção das áreas funcionais 
quanto a adicionar mais pessoas. E explicou: “Qual é a implicação de um patrocinador em Vendas 
tentar iniciar um projeto aprovado pelo PMO? Eles literalmente não entendem o que é um PMO, 
acham que é um tipo de obstáculo para o progresso – algo burocrático”. 
This document is authorized for use only in 2014-04-23 by Estacio_SC1 at Estacio de Sa University from April 2014 
to October 2014.
313-P02 O Escritório de Projeto da AtekPC 
8 
A preocupação de Steinberg sobre como as pessoas poderiam ver o PMO era compartilhada por 
Strider. Apesar de Strider estar convencido que o PMO era o caminho certo para a AtekPC, sabia 
também que tinha de assegurar que a TI mantivesse seu equilíbrio e entregasse o trabalho. Como 
explicou Strider: 
Se você adicionar pessoas, onde você as coloca? O simples fato que você poder adicioná-las 
é uma grande novidade. Você as adiciona neste PMO, ou você as adiciona em algum outro 
lugar?... A questão é como chegar aonde você precisa sem violar tanto a cultura a ponto de 
causar um sinal vermelho... porque o PMO não pode realizar o projeto. Eles não vão escrever 
códigos, nem instalar servidores ou reunir-se com usuários que entendem requisitos funcionais 
e tampouco encontrar-se com os clientes. 
Star estava conseguindo algumas informações sobre este novo PMO pela radio-peão e tentava 
usar o bom senso para entender o que estava ouvindo e ficar pronta para se adaptar a qualquer nova 
mudança. Ela certamente esperava mais ajuda, especialmente com o que ela via como “coisas 
administrativas” do projeto. Como Analista Líder, lidou com muitos dos problemas de 
gerenciamento de projeto e estava com certeza ciente da oportunidade que o PMO criava para ela. 
Esperava aprender a ser mais efetiva como uma gerente de projeto, mas não estava bem certa sobre o 
que realmente estava acontecendo. E descreveu seu entendimento do PMO: 
Achei que seria uma grande ideia porque achava que no momento em que isto se tornasse 
um grupo que iria liderar diferentes projetos, deste grupo viriam os gerentes de projeto líderes. 
E então seríamos a equipe deles. Assumi que o que aconteceria é que eu ainda seria a pessoa 
encarregada – a líder – para aquele projeto, junto ao meu grupo de trabalho. Mas, eu estaria, 
em essência, reportando para este gerente de projeto que tivesse a habilidade e o 
conhecimento, e o treinamento e as ferramentas para nos ajudar a seguir em frente. Porque 
meu histórico em gerenciamento de projetos é baseado em processos e ferramentas 
desenvolvidos por mim mesma para criar, fazer a análise, acompanhar e tudo mais. Portanto 
eu pensava que eles viriam com todas essas ferramentas e que no final eles nos ensinarão a 
sermos gerentes de projeto que podem caminhar sozinhos. 
Gardner, gerente da Star, tinha a expectativa de que o modelo PMO seria mais heavy do que light. 
Já estava convencido dos méritos do PMO pelo uso de seu grupo do “formatação da idéia” para 
capturar novas solicitações de projetos. No seu entendimento, o PMO proveria um pool de recursos 
de gerentes de projetos. E expressou sobre sua visão do modelo organizacional: 
Eles estão mudando o foco, de somente nos ajudar com tipos de metodologia para gerenciar 
projetos... Estão pensando num pool de gerentes de projeto. Você pode ter um projeto e 
emprestar uma pessoa por um tempo. E o seu projeto reportaria a eles. A meu ver, eles têm 
gerentes de projeto para os quais você aloca os vários projetos no departamento. Por exemplo, 
estamos usando um para este novo projeto em lançamento além dos projetos que temos agora. 
Ela está começando a assumir o papel de planejar a linha do tempo, a programação, conseguir 
as pessoas certas no conselho e assegurar que todos sejam informados – as típicas tarefas de 
gerentes de projeto...No que diz respeito ao gerenciamento de projetos, o projeto é sua 
responsabilidade. É seu trabalho. 
Na visão de Gardner, ele manteria o controle do projeto e, durante sua duração, o gerente de 
projeto indicado do pessoal de PMO seguiria suas orientações. Recursos seriam alocados numa 
estrutura matricial durante a duração do projeto. Isto era o que Gardner estava fazendo com o atual 
gerente de projeto do PMO que estava alocado a um de seus projetos, e, na opinião de Gardner, isto 
era de grande ajuda porque ele tinha muito poucas pessoas e uma grande pilha de projetos a serem 
This document is authorized for use only in 2014-04-23 by Estacio_SC1 at Estacio de Sa University from April 2014 
to October 2014.
O Escritório de Projeto da AtekPC 313-P02 
9 
desenvolvidos. Gardner esperava o PMO preenchesse seu grupo com gerentes de projeto de maneira 
similar a um PMO-heavy. 
Por outro lado, Field reconhecia que o problema da estrutura do PMO não era somente quanto ao 
pessoal de TI: 
O problema com o PMO-heavy não é apenas trazer os gerentes de projeto e os analistas, 
mas também os recursos dos negócios. Hoje temos gerentes de linha que estão trabalhando em 
múltiplos projetos além de seus trabalhos regulares e não conseguem fazer mais. O que 
realmente direciona muitos projetos em qualquer companhia é a disponibilidade de recursos 
de negócios para trabalhar nestes projetos. Ter recursos de negócios disponíveis está se 
tornando um problema para nós. Com um PMO-light estaremos mais bem alinhados com o 
lado do negócio em termos de volume de recursos, e portanto, uma situação mais equilibrada. 
Nelson era a favor de um PMO-heavy como melhor modelo para a AtekPC, mas reconhecia que 
não seria capaz de ganhar a aceitação imediata para esta posição. A demanda por recursos era grande 
em toda a AtekPC e o PMO precisaria se justificar para merecer os recursos que queria. Sua intenção 
era construir uma base de apoio para o modelo PMO-heavy por meio de projetos de sucesso. Quando 
o PMO fosse aceito, implantaria a abordagem PMO-heavy, colocando gerentes de projeto nos vários 
grupos. E disse: 
Não acho que se saiba suficientemente sobre gerenciamento de projetos para reconhecer a 
diferença entre PMO light e PMO heavy. Tivemos estruturas organizacionais que foram 
discutidas, mas por causa da mudança geral pela qual a companhia está passando, eles não 
estão prontos para tomar nenhum tipo de decisão... Com estes processos e procedimentos que 
estamos desenvolvendo definiremos o planejamento, acompanhamento, iniciação e 
encerrameno de projetos. Todos os gerentes de projeto ajudarão a colocar a casa da TI em 
ordem. 
Enquanto a AtekPC buscava encontrar o modelo organizacional correto, a equipe de PMO 
trabalhava para entregar os serviços que lentamente construiam sua credibilidade e provando, assim, 
o seu valor para a AtekPC. Encontrar o lugar certo para o PMO ao longo do espectro entre modelos 
organizacionais heavy e light era uma tensão constante que tinha de ser resolvida mais cedo ou mais 
tarde. Com mais recursos, Nelson acreditava que sua equipe poderia prover mais suporte mais 
rápido e seguir adiante mais rapidamente com projetos críticos e padrões. Por outro lado, Strider 
lembrava a Nelson que o PMO era uma de muitas responsabilidades dentro da organização da TI da 
AtekPC. Havia outras necessidades de recursos com suas próprias justificativas e retornos. Portanto, 
a questão de PMO heavy ou PMO light não era uma decisão simples nem fácil. 
Implementação e Cultura 
A AtekPC estava engajada num desafio difícil, tentando implementar métodos-padrão numa 
organização que não estava acostumada a processos e padronizações consistentes e disciplinadores. 
A gestão de TI percebeu que no futuro dependeriam de padrões e processos consistentes para 
gerenciar e tocar seus projetos. Entretanto, implementar um PMO num ambiente não-GP era 
desafiador porque ia contra o fundamento da cultura organizacional. Muitas pessoas dentro da 
AtekPC viam o gerenciamento de projeto somente como custo administrativo indireto – algo que 
inevitavelmente conflita com o “trabalho real”. Field descreveu o desafio cultural ante o novo PMO: 
 Estamos saindo de uma companhia que realmente não tinha nenhum gerenciamento de 
projetos formal para uma companhia que gostaria de ser muito formal. Estamos indo para 
alguma coisa no meio do caminho. Não podemos ser tão rígidos com gerenciamento de 
This document is authorized for use only in 2014-04-23 by Estacio_SC1 at Estacio de Sa University from April 2014 
to October 2014.
313-P02 O Escritório de Projeto da AtekPC 
10 
projetos. Esta cultura não nos deixará fazer isso. Você precisa misturar a cultura com os 
métodos e processos, e até ouvi dizerem onde os processos não podem ser tão rígidos. Se 
ficarmos muito rígidos, fracassaremos. Em certos momentos teremos que ser um pouco fluidos 
e também dinâmicos, e isso preocupa algumas pessoas do PMO, mas aqui temos de fazer isso 
desta maneira. Para ter sucesso precisamos desenvolver uma organização que será flexível e 
também precisa em seus relatórios. Portanto, essa é minha luta – encaixar o gerenciamento de 
projetos na cultura que está mudando, mas que ainda não acabou de mudar. 
Para os envolvidos, as forças opostas ao PMO pareciam ser às vezes majoritárias. Strider 
imaginava o quão disposta estava a organização de TI para mudar seus processos e se adaptar a 
novas práticas de gerenciamento de projetos. Esta era uma questão cultural chave na sua cabeça. 
Muitas pessoas, incluindo gerentes, tinham pouca ou nenhuma experiência em práticas formais de 
gerenciamento de projetos. Muito poucos conheciam como usar certas ferramentas de software 
disponíveis, como o Microsoft Project. Além dessas barreiras de conhecimento, a informalidade das 
práticas atuais era vista como altamente atrativa por muitos. As áreas funcionais apreciavam 
trabalhar com o pessoal de TI, que respondiam rápido às suas necessidades e faziam as coisas 
acontecerem sem demora. O pessoal de TI também achava a informalidade atraente, pois não havia 
nenhum acompanhamento de custos nem nenhum registro de medição dos benefícios resultantes de 
seus projetos, e o pessoal de TI do projeto não estava trabalhando dentro de um orçamento alocado 
ao projeto. Outra fonte de resistência era a falta de entendimento em todos os níveis do valor de 
gerenciamento formal de projetos. Todas estas fontes de resistência ao PMO criavam barreiras 
culturais enormes para seu sucesso, com as quais a gerência e a equipe de PMO tinham de lidar. 
Strider entendia muitas dessas barreiras culturais e reconhecia que teria de encontrar maneiras de 
dribá-las se o PMO quisesse sobreviver. E resumiu a situação, numa discussão recente em seu 
escritório: “Em minha opinião, tenho duas escolhas. Posso me conformar com a cultura e sobreviver, 
ou posso lutar contra a cultura e fracassar... Você só pode nadar contra a corrente até certo ponto, 
independentemente do quão bom e esperto você seja. Mas, se lutar sempre contra a cultura, você 
perderá”. 
Por enquanto, a estratégia de implementação do PMO na AtekPC era a de trabalhar em 
conformidade com a cultura e desenvolver forças que promoveriam o PMO e superariam a 
resistência cultural. Forças promovedoras incluíam o aconselhamento, coaching e treinamento que 
seriam providos pela equipe de PMO. A companhia estava claramente sob pressão para mudar a 
maneira como fazia negócios, mas não havia consenso entre os diretores sobre até que ponto o PMO 
estava integrado ao processo de mudança. Na opinião de Strider era muito cedo para aplicar 
autoridade formal sem evidência de valor e sem um apoio mais disseminado ao conceito PMO. Ele 
acreditava que em primeiro lugar era necessária a adesão das áreas funcionais. Achava que uma das 
maiores questões culturais era o quanto demoraria para que as áreas funcionais(i.e., os clientes de TI) 
se adaptarem a um processo mais formal. Teriam que estar dispostos a priorizar projetos e fazer as 
escolhas difíceis e compensações. Em alguns casos, para seguir adiante com um projeto, eles teriam 
que se dispor a ajudar a justificar recursos adicionais. 
Nelson trabalhava para conseguir a adesão das áreas funcionais, usando sua equipe para fornecer 
aconselhamento e gerenciamento de projetos direto para projetos importantes. Reconhecia que esta 
estratégia de implementação era um trabalho lento e requeria paciência. Para ele, a luta era como 
criar e obter total sucesso. E expressou o desafio como ele o via: 
Não posso chamá-lo de um processo de baixo para cima (sua abordagem de implantação) 
porque conseguimos aprovação do topo para começarmos. É como se estivesse quase no topo, 
mas ainda não inteiramente... É visto como burocrático, ou é visto como tendo o potencial de 
This document is authorized for use only in 2014-04-23 by Estacio_SC1 at Estacio de Sa University from April 2014 
to October 2014.
O Escritório de Projeto da AtekPC 313-P02 
11 
ser burocrático. E isso por causa do próprio setor e seus prazos – entregar produtos, conseguir 
pedidos. Uma das coisas que ouvimos do topo é “só não deixe este gerenciamento de projetos 
e gerenciamento de processos desacelerarem as coisas. Todas essas coisas são legais e 
queremos vê-las funcionando; mas não quero que me atrapalhem”. 
Como Diretor de Desenvolvimento de Aplicativos, Steinberg era um dos primeiros patrocinadores 
do PMO e via vantagens em quebrar estas barreiras culturais. Quando Steinberg veio para a AtekPC, 
logo no começo recebeu a tarefa de implementar uma metodologia-padrão de desenvolvimento de 
software. A tentativa de adoção dessa metodologia fracassou, na opinião dele, porque a cultura não 
estava receptiva a uma abordagem disciplinadora. No momento apoiava totalmente o PMO e 
contribuia com seu profundo entendimento da cultura da AtekPC e seus desafios. Na visão dele, 
somente por meio do trabalho com grupos de negócio um de cada vez se poderia conseguir o seu 
comprometimento com o PMO. E explicou sua opinião: 
A aceitação do PMO fora da TI é um problema. Apesar de tentar com afinco conseguir 
alguma visibilidade fora deste departamento, não fui capaz de conseguir nenhuma. O que 
aconteceu é que começamos a ter nosso pessoal de GP envolvido em projetos e enviá-los aos 
usuários envolvidos. A manufatura foi uma das primeiras áreas. A pessoa que fala pelo projeto 
de TI na Manufatura disse, “O que é que este PMO vai fazer?“ Assim que lhe explicamos, ela 
aderiu. O mesmo aconteceu com Vendas. 
Isto não é tão bem recebido em certos grupos, mas felizmente só em algumas áreas... A 
Manufatura aderiu e Vendas está começando a aderir. Mas não estou certo de que outras áreas 
funcionais já tenham aceitado o conceito. 
Com o apoio de algumas áreas funcionais, a equipe PMO continuou seus esforços de 
implementação. Como frisou Nelson, o avanço deles até à data foi a “passos pequenos”. A frustração 
de um progresso tão tedioso os levava a considerar uma abordagem alternativa – forçar as mudanças 
com ordens de cima para baixo e contratação de especialistas. Vários gerentes, incluindo aqueles 
diretamente envolvidos com o PMO, reconheciam a necessidade de uma equipe maior de 
especialistas para construir padrões e métodos rapidamente, e defendiam uma estratégia de 
implementação mais intensa em termos de recursos. Tal abordagem permitiria ao PMO provar seu 
valor ao gerenciar ativamente mais projetos e ajudar a AtekPC a alcançar um desempenho melhor e 
mais consistente nos projetos. A gestão de TI estava preocupada com a possibilidade fracasso da 
abordagem porque eles não podiam forçar uma mudança radical na AtekPC. Assim, os gerentes 
seniores de TI encorajaram uma estratégia gradual, que permitisse ao conceito PMO se firmar com 
pequenas vitórias por meio do aconselhamento de um projeto de cada vez. 
Governança 
A questão da governança do PMO não estava sendo amplamente discutida, mas já era 
significativa. No momento, não estavam sendo elaborados controles da sua maturação, portanto não 
havia outra maneira de medir o desempenho do PMO que não fosse com base nas opiniões subjetivas 
daqueles envolvidos. Achava-se que a AtekPC saberia se o PMO estava funcionando se os projetos 
estivessem sendo feitos e a companhia conseguindo o que precisava. Field reconhecia que não tinham 
definido como mensurar tanto os projetos como o PMO. E explicou: 
Nos medimos como? Como é que uma organização baseada em projetos mede o seu 
sucesso? Uma das preocupações era que a metodologia gerenciamento de projetos 
desacelerasse as coisas por causa de sua burocracia. Estamos preocupados com isso. Nossa 
intenção é acelerar as coisas e fazê-las mais rapidamente e com menos retrabalho. Mas como é 
This document is authorized for use only in 2014-04-23 by Estacio_SC1 at Estacio de Sa University from April 2014 
to October 2014.
313-P02 O Escritório de Projeto da AtekPC 
12 
que nos avaliamos para dizer que estamos tendo sucesso? Nós ainda nem desenvolvemos as 
métricas necessárias. 
Determinar como evidenciar o valor do PMO era um grande desafio para Nelson: “Só vai 
funcionar se provarmos o seu valor. E isto vai ser difícil porque não fizemos nenhuma coleta de 
dados antes. Mas se for informal, temos que mostrar-lhes... que somos capazes de mostrar 
progresso”. 
Definida esta abordagem para medir o desempenho do PMO, baseada em consenso subjetivo e 
dados informais, o próximo problema de governança era descobrir para quem o PMO respondia. Por 
enquanto reportava-se a Steinberg como Diretor de Desenvolvimento de Aplicativos, o que na 
opinião dele ocorria por causa da sua experiência com metodologias e padrões. E explicou algumas 
das opções de governança: 
Atualmente o PMO reporta-se a mim quanto ao desenvolvimento de aplicativos, mas na 
verdade acho que deveria ser a outra pessoa... Fui definido como sendo a pessoa que daria 
início ao processo. Acho que no futuro deveria reportar-se a outra pessoa – se não for o CIO, a 
alguma outra pessoa na organização... Possivelmente reportar-se ao vice-presidente sênior ou, 
se montarmos o tal Planning Office, então talvez fosse ao Planning Office. 
Strider reconhecia que o modelo atual de governança era apenas temporário e disse o que achava: 
A única razão para estabelecermos um PMO é porque existe um Planning Office para a 
companhia e o vice-presidente sênior está comprometido com uma abordagem mais planejada 
e rigorosa de gerenciamento de projetos. Não posso jogar isso internamente dentro da TI, a 
menos que receba esse apoio... No momento, ele se reporta ao chefe de Desenvolvimento de 
Aplicativos. Steinberg e eu estivemos conversando e achamos, que ao longo do tempo, 
provavelmente o PMO se reportará diretamente a mim. Mas francamente, simplesmente não 
tenho tempo agora... Existe também o Planning Office que não sereporta a mim, mas ao vice-
presidente sênior e essa é uma possibilidade. 
Ao entender esta estreita interação entre o novo Planning Office e o PMO, Steinberg compartilhou 
sua preocupação sobre o PMO permanecer dentro da TI: 
Acho que enquanto se mantiver como uma divisão à parte dentro de TI, continuará a 
questão “nós e eles” e permanecerá o sentimento de que estamos fazendo do nosso jeito para 
parecer bem. Participamos em várias implementações exitosas em grupo e queremos participar 
em outras. Meu desejo é avançar com o PMO, demonstrar os seus benefícios e assim 
influenciar positivamente as outras áreas. 
Decidindo o melhor caminho a seguir 
A indústria de PCs estava mudando e a AtekPC enfrentava fortes pressões de grandes 
competidores como a HP, Dell e Lenovo. Para competir num setor em transformação, no qual 
ocorriam fusões, a AtekPC havia implementado um Planning Office corporativo. Ao reconhecero 
papel que a TI certamente teria de preparar a AtekPC para responder às pressões do setor, o vice 
presidente sênior apoiou a criação de um PMO dentro da TI. O papel do PMO poderia ser ampliado 
para incluir projetos fora da TI, se demonstrasse ser bem sucedido nisso. Ao mesmo tempo, era 
possível que o PMO fracassasse devido ao desafio de implementar uma proposta para projetos 
disciplinadora e com base em medições, num ambiente onde isto era visto como estranho à cultura. 
No final das contas, a AtekPC era uma organização acostumada a pessoas se virando, fazendo tudo 
que precisasse para fabricar e entregar seus produtos diariamente. 
This document is authorized for use only in 2014-04-23 by Estacio_SC1 at Estacio de Sa University from April 2014 
to October 2014.
O Escritório de Projeto da AtekPC 313-P02 
13 
A implementação do PMO já tinha levantado vários problemas, alguns dos quais tinham 
demonstrado serem polêmicos demais para serem resolvidos imediatamente. Na iniciativa PMO, a 
AtekPC se adaptava à medida que as coisas aconteciam. Quando tentavam resolver problemas 
básicos do PMO, todos na organização de TI estavam cientes dos desafios pela frente e o risco 
associado ao fracasso. Os projetos estavam se acumulando rapidamente. O sucesso dependeria 
inteiramente de suas decisões e seus esforços e isto era motivo de preocupação a todos. 
O tráfego parara quando Strider dirigia pela InterEstadual, tentando sair de Metrópolis e chegar a 
casa naquela noite. Teve tempo para refletir novamente sobre o PMO. Conduzira a sua equipe 
gerencial para esta estratégia de implantação e estava bem convencido de que o modelo PMO-light 
deveria ser o escolhido. Tinha segurado a contratação de mais empregados em tempo integral para o 
PMO. E estava preocupado com muitas questões que a implementação do PMO já tinha levantado. 
Será que dando pequenos passos e alcançar pequenos sucessos, conseguiria entregar o trabalho 
rápido o suficiente? E pensou consigo mesmo enquanto esperava o trânsito voltar a andar: “Como 
chego aonde precisamos ir, sem violar a cultura a ponto de levantarem uma bandeira vermelha?... 
Sinto que tenho de agir como estou agindo, ao invés de montar um grande PMO e dizer, “Aqui está o 
meu PMO’”. 
 
This document is authorized for use only in 2014-04-23 by Estacio_SC1 at Estacio de Sa University from April 2014 
to October 2014.
3
1
3
-P
0
2
 
 
 -
1
4
- 
F
ig
u
ra
 1
O
rg
an
o
g
ra
m
a 
d
a 
A
te
k
P
C
 I
n
fo
rm
at
io
n
 T
ec
h
n
o
lo
g
y
 
C
h
ie
f
I
n
f
o
r
m
a
ti
o
n
O
f
f
ic
e
r
J
o
h
n
 S
t
r
i
d
e
r
D
ir
e
to
r
 d
e
 D
e
s
e
n
v
o
lv
im
e
n
to
 
d
e
 A
p
li
c
a
ç
ã
o
R
i
c
h
a
r
d
 S
t
e
i
n
b
e
r
g
D
ir
e
to
r
 d
e
 O
p
e
r
a
ç
õ
e
s
 
&
 T
e
c
n
o
lo
g
ia
G
e
r
e
n
te
 d
e
 V
e
n
d
a
s
 d
e
 
S
is
te
m
a
s
G
e
r
e
n
te
 F
a
b
r
ic
a
ç
ã
o
 d
e
 
S
is
te
m
a
s
S
t
e
v
e
n
 G
a
r
d
n
e
r
G
e
r
e
n
te
 d
e
 S
is
te
m
a
s
 
F
in
a
n
c
e
ir
o
s
D
ir
e
to
r
 G
r
u
p
o
 S
u
p
o
r
te
 
G
e
s
tã
o
 d
e
 P
r
o
je
to
s
L
a
r
r
y
 F
i
e
l
d
G
e
r
e
n
te
 G
r
u
p
o
 d
e
 
T
r
a
b
a
lh
o
 C
o
m
u
n
ic
a
ç
õ
e
s
G
e
r
e
n
te
 R
e
p
o
s
iç
ã
o
 
S
is
te
m
a
s
 A
v
a
n
ç
a
d
o
s
A
n
a
li
s
ta
 L
íd
e
r
L
i
n
d
a
 S
t
a
r
r
A
n
a
li
s
ta
 L
íd
e
r
A
n
a
li
s
ta
 L
íd
e
r
A
n
a
li
s
ta
 L
íd
e
r
A
n
a
li
s
ta
 L
íd
e
r
D
ir
e
to
r
 P
M
O
M
a
r
k
 N
e
ls
o
n
G
e
r
e
n
te
 d
e
 P
r
o
je
to
G
e
r
e
n
te
 d
e
 
P
r
o
je
to
 
 
This document is authorized for use only in 2014-04-23 by Estacio_SC1 at Estacio de Sa University from April 2014 
to October 2014.
O Escritório de Projeto da AtekPC 313-P02 
15 
Figura 2 Formulário de Ideias da AtekPC 
FORMULÁRIO DE DESENVOLVIMENTO DE IDEIA
Seção A. (Solicitante preenche essa seção)
Nome do Solicitante:
Data Submissão da Solicitação:
Nome do Sistema (se conhecido):
Necessário para Data:
Nome do Projeto:
Seção B.
(Revisor preenche essa seção)
Revisor da Ideia:
Data de Revisão:
ID do Projeto:
 Aprovado
 Reprovado - Razão para reprovação:
Seção C. Tipo de Trabalho (Revisor preenche essa seção)
 Melhoria  Emergência  Correção
Seção D. (Solicitante preenche essa seção)
1. Faça uma Descrição (O que é):
2. Por que devemos fazer isso? (Explique o valor de negócio e selecione o tipo de benefício apropriado)
Explicação:
Tipo de Benefício (mas de um tipo pode ser aplicado) Estime se possível
 Cria Receita Estimativa de receita anual:_____________
 Evita Custos Estimativa de corte de custos:___________
 Economiza Custos Estimativa de economia de custos:_______
 Confiabilidade Operacional
 Melhoria do Atendimento do Consumidor
 Melhoria da Qualidade
3. Escopo (Descreva o que inclui e exclui.)
4. Entregas (Relate mudanças, nova tela, entrada de dados, etc...)
5. Departamentos/Clientes Impactados
6. Premissas
7. Projetos relacionados
8. Risco/Impacto de não fazer o projeto
 
This document is authorized for use only in 2014-04-23 by Estacio_SC1 at Estacio de Sa University from April 2014 
to October 2014.