313-P02

11 DE OUTUBRO DE 2007

F. WARREN MCFARLAN
JOHN HUPP
MARK KELL

O PMO (Escritrio de Gesto de Projetos) da

AtekPC
Tinha comeado a chover no comeo da noite de 3 de maro de 2007 e as ruas de Metrpolis,
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 Escritrio de Gesto de
Projetos (do ingls Project Management Office - PMO) que ele havia aprovado vrios meses antes.
Durante os mais de 20 anos de sua gesto na AtekPC, Strider nunca tinha testemunhado o tipo de
presso que o setor de computadores pessoais (Personal Computer - PC) vinha enfrentando. Strider
reconhecia que o setor estava em transio e que a sua Tecnologia da Informao estaria envolvida
em alguns projetos crticos e importantes, enquanto a AtekPC procurava tomar a liderana nestas
mudanas. 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 invs de ajudar, poderia tornar-se
outro item na sua crescente lista de problemas. Havia muitas questes na sua cabea com relao 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 definio de sucesso no comeo? 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 benefcio deste PMO para a AtekPC, mas a iniciativa ainda estava
no comeo, precisava de tempo para dar provas de sua eficincia. 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 negcio de PCs e na AtekPC no entendiam o quo 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 mudanas durante um bom perodo 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 no podia se dedicar somente construo deste novo PMO. Tudo tinha de ser feito
em conjunto. Strider sabia da frustrao do pessoal dele que estava trabalhando no PMO por no
poder ir mais rpido. E ele tambm estava tentado a pensar em destinar rapidamente mais recursos
para o PMO e nocautear projetos. Mas em sua opinio, isso seria uma iniciativa de vida curta muita
coisa, muito cedo, muito rpido.
________________________________________________________________________________________________________________
Caso LACC # 313-P02 a verso traduzida para Portugus do caso # 308-049 da HBS. Os casos da HBS so desenvolvidos somente como base
para discusses em classe. Casos no devem servir como aprovao, fonte primria de dados ou informao, ou como ilustrao de um
gerenciamento eficaz ou ineficaz.
Copyright 2013 President and Fellows of Harvard College. Nenhuma parte desta publicao pode ser reproduzida, armazenada em um sistema
de dados, usada em uma tabela de dados, ou transmitida de qualquer forma ou por qualquer meio - eletrnico, mecnico, fotocopiada, gravada,
ou qualquer outra - sem a permisso da Harvard Business School.

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 Escritrio de Projeto da AtekPC

Strider fechou a pasta e dirigiu-se ao o elevador. Sua equipe gerencial snior 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 direes estratgicas de negcio com recursos de TI e essa era a essncia do PMO. Havia
pouca margem para erros na AtekPC nestes tempos de mudanas.

Histrico do Setor
O setor de PCs experimentava uma tremenda presso dos custos e passava por um perodo de
consolidao. medida que as margens de lucro caiam, os fabricantes de PCs lanavam estratgias
de reduo de custos que buscavam melhorar a eficincia de suas cadeias de suprimentos, enquanto
baixavam o custo de distribuio. De acordo com um artigo recente de jornal:
Os ltimos resultados financeiros dos fabricantes de PCs mostram uma desacelerao nas
vendas e lucratividade. Corporaes e consumidores esto mantendo seus PCs por um perodo
mais longo de tempo para evitar o custo e os distrbios associados atualizao de seus
equipamentos. Como resultado, compras esto sendo prorrogadas e fabricantes de PCs esto
olhando novos mercados para oportunidades de crescimento. O setor parece estar passando
por uma onda de consolidao medida que o controle de custos e escala se tornam mais
importantes do que nunca.
Em 2007, uma grande revista de notcias publicou um artigo de capa intitulado Os rumos do
PC? As ameaas reportadas na anlise eram mundiais e vinham de uma variedade de fatores
incluindo a crescente popularidade dos telefones mveis, 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,
empresrios e consumidores se beneficiam ao acessarem emails de qualquer lugar 24 horas por
dia, 7 dias por semana, sem a inconvenincia de carregar consigo um notebook. Atualmente,
telefones mveis 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 esto comprando
mquinas mais baratas que podem acessar e rodar aplicativos baseados na web e no
requerem muito poder de processamento local ou armazenamento. Tendo ignorado a
realidade por anos, os fabricantes de PCs finalmente esto fazendo alguma coisa. Para cortar
custos, esto rearranjando suas operaes por meio do uso da tecnologia da informao 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 mdio de PCs nos
EUA, com vendas de $1,9 bilhes em 2006. Empregava 2.100 trabalhadores em tempo integral e
outros 200 trabalhadores em tempo parcial. Apesar de sua histria de rpido crescimento nos anos
1990, a AtekPC lutava em conjunto com outros fabricantes de PCs do mundo enquanto lidavam com
a transio 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 alcanou altas taxas de crescimento e boas margens de lucro. Como resultado,
2
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 Escritrio de Projeto da AtekPC

313-P02

tendemos a no ser to cuidadosos quanto deveramos no controle de custos e ao lidar com

ameaas competitivas. Agora, claro, a realidade mudou e estamos encarando uma crescente
competio dos fabricantes asiticos de PCs, que fizeram a transio de fabricantes contratados
para vendedores de suas prprias marcas de PCs.
O setor de PCs est passando por uma certa consolidao com grandes players adquirindo
players menores para conseguir maior escala. Portanto, este hoje o cenrio 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 competncias sejam mais consistentes com o que
nosso nome implica. No futuro, teremos de ser muito mais sbios em termos de uso de TI ou
arriscaremos nos tornar no lucrativos ou alvo de aquisies hostis.
No outono de 2006, a AtekPC j tinha comeado vrias iniciativas com o objetivo de posicionar a
organizao para o futuro. Uma dessas iniciativas era o estabelecimento de um Strategic Planning
Office, cuja responsabilidade era propor mudanas de negcios. Sob os auspcios do Strategic
Planning Office, o esforo 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 maro de 2007, o
Strategic Planning Office e o PMO inicial estavam em operao h alguns meses. De acordo com
Strider, a AtekPC enfrentava intensa competio de preos e a gesto da empresa sofria forte presso
para assegurar que cada ao tivesse um retorno visvel.

A Tecnologia da Informao na AtekPC

Ao longo dos anos a AtekPC desenvolveu um extenso portflio de aplicativos. Estes aplicativos
eram principalmente focados no nvel operacional das funes de negcio tpicas de um fabricante de
PC, tais como contabilidade, suprimentos, manufatura, vendas e distribuio. A integrao da
arquitetura destes sistemas de aplicativos era apenas moderada, tanto que em 2007, as reas
funcionais normalmente recebiam informaes com pouca integrao multifuncional. Projetos de
sistema de informao eram tipicamente esforos operacionais ou de manuteno feitos atravs da
solicitao de uma determinada rea funcional. Eram geralmente projetos de pequenos a mdios em
termos de tamanho e durao, e gerenciados informalmente sem prticas padronizadas. Como
explicou o Diretor de Desenvolvimento de Aplicativos, Richard Steinberg:
Ns sempre fizemos do nosso jeito. Tnhamos 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
fazamos nos projetos poderia ser melhorada. Quando comeamos a dar uma olhada no que
precisvamos fazer no futuro, percebemos que tnhamos de realmente aprimorar nossas
habilidades para sermos capazes de nos mover mais agressivamente e de lidar com mltiplos
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 mudana que a AtekPC enfrentava criava vrios desafios que se planejava encarar
com projetos grandes e complexos. O novo PMO estava sendo introduzido para prover a
padronizao 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 prticas formais, estes projetos no resultaram numa formalizao duradoura
das prticas. Steinberg explicou:

3
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 Escritrio de Projeto da AtekPC

Voc pode retroceder alguns anos, ao Y2K, para a converso de nosso sistema de gesto de
pedidos; nesses grandes projetos usaram uma abordagem de gerenciamento de projeto. No se
deram conta disso. Juntou-se todo mundo, falou-se sobre quanto tempo levaria para fazer isso
e eles fizeram. Todos receberam prmios e disseram, Foi tudo muito bem feito. Agora que
acabou, temos de voltar a fazer projetos normalmente. No se percebeu que esta a maneira
de se fazer. De repente quando aquelas coisas grandes terminaram, quando desapareceram,
ento se voltou a tentar fazer coisas tiradas da cartola novamente.
Em 2007, os projetos de TI eram normalmente gerenciados atravs da adio de responsabilidade
de GP a uma das pessoas de desenvolvimento, que eram alocadas para reas funcionais especficas.
Por exemplo, o Analista Lder alocado para manufatura tambm desempenhava o papel de gerente
de projeto. Analistas Lderes supervisionavam grupos de trabalho de analistas e programadores de
diferentes nveis de conhecimento, e eram responsveis por satisfazer os requisitos das reas
funcionais assim como o desempenho de seus grupos de trabalho. Usando um processo informal de
iniciao, usurios requisitavam servios de TI atravs do Analista Lder, que ento 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 necessrio; caso contrrio, a
solicitao era recebida, executada e entregue atravs do Analista Lder. Mtodos, documentao,
prticas e ferramentas de projeto eram individualizadas pelo Analista Lder com pouca ou nenhuma
consistncia entre grupos de TI ou reas de negcio.
A AtekPC percebia muitos benefcios nesta abordagem informal de projetos. Os Analistas Lderes
frequentemente estavam h muito tempo em suas reas e conheciam profundamente as atividades do
negcio, necessidades e pessoas. Como resultado de suas abordagens informais, respondiam
rapidamente s solicitaes dos usurios e eram capazes de balancear necessidades crticas
emergenciais dentro de seus grupos de trabalho, com poucos conflitos. Por causa do histrico de
entrega rpida, havia considervel confiana desenvolvida entre a rea funcional e seus Analistas
Lderes. A relao de confiana era muito personalizada e lealdades surgiam de ambos os lados. A
abertura destas relaes permitia ao Analista Lder juntar e avaliar rapidamente os requisitos e
chegar ao consenso sobre um cronograma e data de entrega. Linda Star, uma Analista Lder da
Manufatura, descreveu seu trabalho neste papel:
No meu mundo tenho uma variedade de usurios com quem converso. Eles dizem,
Preciso disso. Alguns dizem, Realmente preciso disso. possvel? Isto uma emergncia 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... Fao 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 viso prevalecente era que a TI era perifrica s atividades base de negcio na
AtekPC. Como resultado, a TI era vista como uma tomadora de pedidos, da qual se esperava a
prestao de servios sob demanda. Na dcada anterior, os projetos tornaram-se cada vez mais
focados em operaes e manuteno, num esforo para melhorar eficincias dentro das funes de
negcios. O desenvolvimento de sistemas de integrao multifuncional e o uso de tecnologias de
internet foram somente duas das muitas necessidades emergentes enquanto a AtekPC lutava com
mudanas radicais no seu setor e mercado. Os projetos novos requeridos eram maiores, mais
complexos e envolviam mltiplas reas funcionais e mltiplas reas tecnolgicas, 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 mtodos informais de gesto de projetos. O
PMO AtekPC estava sendo implementado para garantir prticas melhores e mais consistentes para
4
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 Escritrio de Projeto da AtekPC

313-P02

projetos de negcio de TI. Entretanto, implementar um PMO na AtekPC era, em si mesmo, um

desafio que requeria uma habilidosa gesto para ter sucesso. Um equilbrio difcil tinha de ser
mantido entre manuteno 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:
No temos tudo definido. Isso melhor que pensar que temos e no ter. No departamento
de TI temos de ser mais capazes de gerir os conflitos entre novas iniciativas crticas de negcio
e operaes com mudanas adicionais aos sistemas existentes. No podemos sacrificar um pelo
outro. A questo que fazamos somente manuteno operacional e agora precisamos ter uma
cultura de fazer ambos.

Misso do PMO
A misso do PMO da AtekPC tinha evoludo gradualmente desde seu incio no final de 2006. Na
primavera de 2007, no havia um consenso completo em relao a seu propsito, suas
responsabilidades e sua autoridade. Apesar de no existirem planos e documentao formal para o
PMO, a meta imediata era estabelecer o escritrio e provar o seu valor. O consenso geral era que o
propsito do PMO era conseguir benefcios derivados de prticas consistentes de projetos. Apesar de
no estarem claramente especificados ou serem mensurveis nesse momento, estes benefcios eram
expressos em uma variedade de termos incluindo melhorias de TI no desempenho dos projetos e
utilizao de recursos, a melhorias corporativas na gesto de custos e competncia corporativa para
lanar 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 reduo de custos. No podemos ser
descuidados. Francamente, temos de ser muito mais cuidadosos ao usar nossos recursos. Outra
motivao para melhorarmos nossos projetos e sermos mais criativos, adaptveis e geis em
lanar novos produtos. E para lanar novos produtos, o que voc diria que est impulsionando
estas iniciativas, seno o gerenciamento de projetos?
Contudo, as responsabilidades do PMO no eram assim to claras. Naquele momento, as
responsabilidades do PMO estavam limitadas a projetos de TI, apesar das discusses sobre expandir
seu escopo para um PMO em nvel corporativo que incluiria projetos de negcio no futuro. As tarefas
especficas de um PMO eram tipicamente divididas em duas categorias: focado em projeto e
orientado para a corporao. As responsabilidades com foco em projeto tais como consultoria,
aconselhamento (do ingls mentoring, quando um profissional mais velho e experimente orienta os
mais jovens) e treinamento eram servios que capacitavam o sucesso individual dos projetos. Por
outro lado, as responsabilidades corporativas tratavam de servios que poderiam melhorar todos os
projetos tais como gesto de portflio, padres de GP, mtodos e ferramentas, e desempenho do
projeto. A definio das responsabilidades do PMO estava em constante evoluo enquanto a AtekPC
tentava ganhar apoio e conseguir definir a sua misso e charter:
Na AtekPC, as responsabilidades focadas em projeto eram os principais meios usados para provar
os mritos de seu PMO. O plano era criar aceitao por meio de consultoria e aconselhamento sobre
projetos individuais. Mark Nelson, o novo Gerente de PMO, falou sobre este esforo:
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 reunies regulares com as equipes, relatrios de posio,
questes de manuteno e gesto de riscos.
5
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 Escritrio de Projeto da AtekPC

Para esse fim, o PMO continuou a obter suporte das reas funcionais e do pessoal de TI
envolvidos nos projetos. Uma das maiores limitaes era a escassez de pessoal especializado em PMO
disponvel para ajudar nestes projetos. Alm de Nelson, havia outros trs 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 crtico envolvendo o lanamento de um novo computador notebook.
A AtekPC no priorizava o desenvolvimento de pessoal com postura empresarial para o PMO. O
novo PMO desenvolvera alguns processos e procedimentos padro 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 formatao da ideia, onde
tentamos eliminar muitas chamadas aleatrias que nos chegam. Estamos tentando priorizar
melhor o que trabalhamos e usar esta formatao da ideia nos leva a entender o negcio a
partir de qualquer ideia que surja. Isto nos fora 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 razo para fazer isso? Vale a pena fazer este projeto custa de
outro? E agora, como fao para priorizar? Portanto, est nos ajudando a nos aproximarmos
daquilo em que estamos trabalhando.
Os servios 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 responsvel por definir, publicar e
disseminar prticas de projeto, padres e ferramentas. Por outro lado, gesto de portflio (a mudana
de gerenciar um projeto para a definio de tcnicas para gerenciar um fluxo contnuo de projeto) e
responsabilidades por arquivamentos (a definio de registros de projetos para compartilhamento do
conhecimento) no estavam sendo tratadas. Nelson esperava ser capaz de incluir estas obrigaes na
misso quando o PMO se desenvolvesse, mas sem recursos adicionais no era factvel no curto prazo.
Ele tambm percebeu que s disporiam de recursos adicionais se tirassem de outras
responsabilidades crticas e isto poderia comprometer sua capacidade de manter a eficcia
operacional. Conseguir esse equilbrio era desafiador.
A ltima rea de preocupao em relao misso do PMO era a questo da autoridade. Strider
reconhecia que a fiscalizao destas novas prticas de projeto requeria autoridade formal e estava
preparado para conced-la somente quando o PMO fosse aprovado pelas reas de negcio e de TI.
Nos esforos iniciais de desenvolvimento, Nelson tinha a vantagem de trabalhar com uma autoridade
implcita vinda da percepo geral de mudana no direcionamento gerencial. Entretanto, o PMO
tambm tinha o apoio do VP snior, Larry Field, Diretor do Grupo de Suporte de Gerenciamento de
Projetos e pea chave da iniciativa PMO desde o seu incio. Ele explicou: Para sermos efetivos, temos
de ter apoio de cima. E temos apoio da vice-presidncia atravs de John Strider e da para baixo. Essa
a primeira e a mais crtica 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 servios do PMO. Mesmo isso era limitado quelas reas funcionais e s de TI ativamente
engajadas no PMO. No havia nenhum plano concreto para fiscalizar o uso em nvel corporativo.
Nelson resumiu esta abordagem com esta colocao:
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
6
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 Escritrio de Projeto da AtekPC

313-P02

levar um ano e meio, estamos conseguindo fazer em trs ou quatro meses porque colocamos
estas prticas para funcionar. E isso a chave porque nos permite mostrar nosso valor. Esta
tem de ser a abordagem por enquanto.

A Organizao PMO
Estavam sendo considerados dois modelos organizacionais para o PMO o PMO-heavy e PMOlight, 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 gesto do todo. Este modelo focava na aquisio de especialistas de gesto de
projetos sob a direo do PMO. Na verso extrema do PMO-heavy, nenhum projeto operava fora da
gesto e controle direto do PMO. No outro extremo do espectro, o PMO-light era caracterizado pela
equipe mnima 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 no estavam formalmente conectados com o PMO. Na verso extrema do PMOlight, 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 execuo do projeto.
A definio do PMO, no espectro entre PMO-heavy e PMO-light, estava gerando muita discusso e
pouco entendimento. Strider pronunciou-se sobre esta controvrsia:
Exatamente agora temos quatro pessoas em tempo integral... Dada a velocidade na qual
ns, como empresa, queremos nos mover e ns como uma indstria 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. No vejo toda a gesto
movendo-se para este grupo. Existe uma diferena de opinio entre mim e o PMO neste ponto.
Temos de encontrar um meio termo... estou suficientemente convencido de que deveria ser
light. Isso no significa que no me questione, porque h muitas pessoas neste departamento
que esto constantemente me desafiando em relao a isso. O que bom, quer dizer, nunca
quis um bando de cordeirinhos ao meu redor.
Apesar da concordncia de Nelson em trabalhar com uma equipe pequena no incio, ele sentia que
atrasos poderiam comprometer a capacidade deles em prestar os servios de PMO e em demonstrar
seu benefcio para as reas funcionais do negcio. Entretanto, ele e outros gerentes reconheciam que
os recursos no eram de graa e tinham de vir de algum lugar, o que significava sacrificar as
atividades de uma pessoa para avanar 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 no houvesse nenhuma restrio, gostaria de ter montado a equipe muito rapidamente
com analistas de projeto e com gerentes. Juntar um grupo de pessoas no comeo. A maioria
deles poderia ser de novatos no incio. A partir da, medida que se caminha, voc poderia
trazer o restante da organizao. Todos seriam parte do PMO. Portanto teramos graus
variados de experincia, desde GPs seniores at pessoas juniores. Conseguiramos muita coisa
somente com esse passo.
Steinberg preocupava-se com os recursos requeridos e qual a percepo das reas funcionais
quanto a adicionar mais pessoas. E explicou: Qual a implicao de um patrocinador em Vendas
tentar iniciar um projeto aprovado pelo PMO? Eles literalmente no entendem o que um PMO,
acham que um tipo de obstculo para o progresso algo burocrtico.

7
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 Escritrio de Projeto da AtekPC

A preocupao 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
tambm que tinha de assegurar que a TI mantivesse seu equilbrio 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 questo como chegar aonde voc precisa sem violar tanto a cultura a ponto de
causar um sinal vermelho... porque o PMO no pode realizar o projeto. Eles no vo escrever
cdigos, nem instalar servidores ou reunir-se com usurios que entendem requisitos funcionais
e tampouco encontrar-se com os clientes.
Star estava conseguindo algumas informaes sobre este novo PMO pela radio-peo e tentava
usar o bom senso para entender o que estava ouvindo e ficar pronta para se adaptar a qualquer nova
mudana. Ela certamente esperava mais ajuda, especialmente com o que ela via como coisas
administrativas do projeto. Como Analista Lder, 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 no 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 lderes.
E ento seramos a equipe deles. Assumi que o que aconteceria que eu ainda seria a pessoa
encarregada a lder para aquele projeto, junto ao meu grupo de trabalho. Mas, eu estaria,
em essncia, 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 histrico em gerenciamento de projetos baseado em processos e ferramentas
desenvolvidos por mim mesma para criar, fazer a anlise, acompanhar e tudo mais. Portanto
eu pensava que eles viriam com todas essas ferramentas e que no final eles nos ensinaro 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 mritos do PMO pelo uso de seu grupo do formatao da idia para
capturar novas solicitaes de projetos. No seu entendimento, o PMO proveria um pool de recursos
de gerentes de projetos. E expressou sobre sua viso do modelo organizacional:
Eles esto mudando o foco, de somente nos ajudar com tipos de metodologia para gerenciar
projetos... Esto 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 tm
gerentes de projeto para os quais voc aloca os vrios projetos no departamento. Por exemplo,
estamos usando um para este novo projeto em lanamento alm dos projetos que temos agora.
Ela est comeando a assumir o papel de planejar a linha do tempo, a programao, conseguir
as pessoas certas no conselho e assegurar que todos sejam informados as tpicas tarefas de
gerentes de projeto... No que diz respeito ao gerenciamento de projetos, o projeto sua
responsabilidade. seu trabalho.
Na viso de Gardner, ele manteria o controle do projeto e, durante sua durao, o gerente de
projeto indicado do pessoal de PMO seguiria suas orientaes. Recursos seriam alocados numa
estrutura matricial durante a durao 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 opinio de Gardner, isto
era de grande ajuda porque ele tinha muito poucas pessoas e uma grande pilha de projetos a serem

8
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 Escritrio de Projeto da AtekPC

313-P02

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 no era somente quanto ao
pessoal de TI:
O problema com o PMO-heavy no apenas trazer os gerentes de projeto e os analistas,
mas tambm os recursos dos negcios. Hoje temos gerentes de linha que esto trabalhando em
mltiplos projetos alm de seus trabalhos regulares e no conseguem fazer mais. O que
realmente direciona muitos projetos em qualquer companhia a disponibilidade de recursos
de negcios para trabalhar nestes projetos. Ter recursos de negcios disponveis est se
tornando um problema para ns. Com um PMO-light estaremos mais bem alinhados com o
lado do negcio em termos de volume de recursos, e portanto, uma situao mais equilibrada.
Nelson era a favor de um PMO-heavy como melhor modelo para a AtekPC, mas reconhecia que
no seria capaz de ganhar a aceitao imediata para esta posio. A demanda por recursos era grande
em toda a AtekPC e o PMO precisaria se justificar para merecer os recursos que queria. Sua inteno
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 vrios
grupos. E disse:
No acho que se saiba suficientemente sobre gerenciamento de projetos para reconhecer a
diferena entre PMO light e PMO heavy. Tivemos estruturas organizacionais que foram
discutidas, mas por causa da mudana geral pela qual a companhia est passando, eles no
esto prontos para tomar nenhum tipo de deciso... Com estes processos e procedimentos que
estamos desenvolvendo definiremos o planejamento, acompanhamento, iniciao e
encerrameno de projetos. Todos os gerentes de projeto ajudaro 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 servios 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 tenso constante que tinha de ser resolvida mais cedo ou mais
tarde. Com mais recursos, Nelson acreditava que sua equipe poderia prover mais suporte mais
rpido e seguir adiante mais rapidamente com projetos crticos e padres. Por outro lado, Strider
lembrava a Nelson que o PMO era uma de muitas responsabilidades dentro da organizao da TI da
AtekPC. Havia outras necessidades de recursos com suas prprias justificativas e retornos. Portanto,
a questo de PMO heavy ou PMO light no era uma deciso simples nem fcil.

Implementao e Cultura
A AtekPC estava engajada num desafio difcil, tentando implementar mtodos-padro numa
organizao que no estava acostumada a processos e padronizaes consistentes e disciplinadores.
A gesto de TI percebeu que no futuro dependeriam de padres e processos consistentes para
gerenciar e tocar seus projetos. Entretanto, implementar um PMO num ambiente no-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 no tinha nenhum gerenciamento de
projetos formal para uma companhia que gostaria de ser muito formal. Estamos indo para
alguma coisa no meio do caminho. No podemos ser to rgidos com gerenciamento de
9
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 Escritrio de Projeto da AtekPC

projetos. Esta cultura no nos deixar fazer isso. Voc precisa misturar a cultura com os
mtodos e processos, e at ouvi dizerem onde os processos no podem ser to rgidos. Se
ficarmos muito rgidos, fracassaremos. Em certos momentos teremos que ser um pouco fluidos
e tambm dinmicos, e isso preocupa algumas pessoas do PMO, mas aqui temos de fazer isso
desta maneira. Para ter sucesso precisamos desenvolver uma organizao que ser flexvel e
tambm precisa em seus relatrios. Portanto, essa minha luta encaixar o gerenciamento de
projetos na cultura que est mudando, mas que ainda no acabou de mudar.
Para os envolvidos, as foras opostas ao PMO pareciam ser s vezes majoritrias. Strider
imaginava o quo disposta estava a organizao de TI para mudar seus processos e se adaptar a
novas prticas de gerenciamento de projetos. Esta era uma questo cultural chave na sua cabea.
Muitas pessoas, incluindo gerentes, tinham pouca ou nenhuma experincia em prticas formais de
gerenciamento de projetos. Muito poucos conheciam como usar certas ferramentas de software
disponveis, como o Microsoft Project. Alm dessas barreiras de conhecimento, a informalidade das
prticas atuais era vista como altamente atrativa por muitos. As reas funcionais apreciavam
trabalhar com o pessoal de TI, que respondiam rpido s suas necessidades e faziam as coisas
acontecerem sem demora. O pessoal de TI tambm achava a informalidade atraente, pois no havia
nenhum acompanhamento de custos nem nenhum registro de medio dos benefcios resultantes de
seus projetos, e o pessoal de TI do projeto no estava trabalhando dentro de um oramento alocado
ao projeto. Outra fonte de resistncia era a falta de entendimento em todos os nveis do valor de
gerenciamento formal de projetos. Todas estas fontes de resistncia ao PMO criavam barreiras
culturais enormes para seu sucesso, com as quais a gerncia 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 situao, numa discusso recente em seu
escritrio: Em minha opinio, 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 quo bom e esperto voc seja. Mas, se lutar sempre contra a cultura, voc
perder.
Por enquanto, a estratgia de implementao do PMO na AtekPC era a de trabalhar em
conformidade com a cultura e desenvolver foras que promoveriam o PMO e superariam a
resistncia cultural. Foras promovedoras incluam o aconselhamento, coaching e treinamento que
seriam providos pela equipe de PMO. A companhia estava claramente sob presso para mudar a
maneira como fazia negcios, mas no havia consenso entre os diretores sobre at que ponto o PMO
estava integrado ao processo de mudana. Na opinio de Strider era muito cedo para aplicar
autoridade formal sem evidncia de valor e sem um apoio mais disseminado ao conceito PMO. Ele
acreditava que em primeiro lugar era necessria a adeso das reas funcionais. Achava que uma das
maiores questes 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 difceis e compensaes. 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 adeso das reas funcionais, usando sua equipe para fornecer
aconselhamento e gerenciamento de projetos direto para projetos importantes. Reconhecia que esta
estratgia de implementao era um trabalho lento e requeria pacincia. Para ele, a luta era como
criar e obter total sucesso. E expressou o desafio como ele o via:
No posso cham-lo de um processo de baixo para cima (sua abordagem de implantao)
porque conseguimos aprovao do topo para comearmos. como se estivesse quase no topo,
mas ainda no inteiramente... visto como burocrtico, ou visto como tendo o potencial de
10
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 Escritrio de Projeto da AtekPC

313-P02

ser burocrtico. E isso por causa do prprio setor e seus prazos entregar produtos, conseguir
pedidos. Uma das coisas que ouvimos do topo s no deixe este gerenciamento de projetos
e gerenciamento de processos desacelerarem as coisas. Todas essas coisas so legais e
queremos v-las funcionando; mas no 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 comeo recebeu a tarefa de implementar uma metodologia-padro de desenvolvimento de
software. A tentativa de adoo dessa metodologia fracassou, na opinio dele, porque a cultura no
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 viso dele,
somente por meio do trabalho com grupos de negcio um de cada vez se poderia conseguir o seu
comprometimento com o PMO. E explicou sua opinio:
A aceitao do PMO fora da TI um problema. Apesar de tentar com afinco conseguir
alguma visibilidade fora deste departamento, no fui capaz de conseguir nenhuma. O que
aconteceu que comeamos a ter nosso pessoal de GP envolvido em projetos e envi-los aos
usurios 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 no to bem recebido em certos grupos, mas felizmente s em algumas reas... A
Manufatura aderiu e Vendas est comeando a aderir. Mas no estou certo de que outras reas
funcionais j tenham aceitado o conceito.
Com o apoio de algumas reas funcionais, a equipe PMO continuou seus esforos de
implementao. Como frisou Nelson, o avano deles at data foi a passos pequenos. A frustrao
de um progresso to tedioso os levava a considerar uma abordagem alternativa forar as mudanas
com ordens de cima para baixo e contratao de especialistas. Vrios gerentes, incluindo aqueles
diretamente envolvidos com o PMO, reconheciam a necessidade de uma equipe maior de
especialistas para construir padres e mtodos rapidamente, e defendiam uma estratgia de
implementao mais intensa em termos de recursos. Tal abordagem permitiria ao PMO provar seu
valor ao gerenciar ativamente mais projetos e ajudar a AtekPC a alcanar um desempenho melhor e
mais consistente nos projetos. A gesto de TI estava preocupada com a possibilidade fracasso da
abordagem porque eles no podiam forar uma mudana radical na AtekPC. Assim, os gerentes
seniores de TI encorajaram uma estratgia gradual, que permitisse ao conceito PMO se firmar com
pequenas vitrias por meio do aconselhamento de um projeto de cada vez.

Governana
A questo da governana do PMO no estava sendo amplamente discutida, mas j era
significativa. No momento, no estavam sendo elaborados controles da sua maturao, portanto no
havia outra maneira de medir o desempenho do PMO que no fosse com base nas opinies 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 no tinham
definido como mensurar tanto os projetos como o PMO. E explicou:
Nos medimos como? Como que uma organizao baseada em projetos mede o seu
sucesso? Uma das preocupaes era que a metodologia gerenciamento de projetos
desacelerasse as coisas por causa de sua burocracia. Estamos preocupados com isso. Nossa
inteno acelerar as coisas e faz-las mais rapidamente e com menos retrabalho. Mas como

11
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 Escritrio de Projeto da AtekPC

que nos avaliamos para dizer que estamos tendo sucesso? Ns ainda nem desenvolvemos as
mtricas necessrias.
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 difcil porque no 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 prximo problema de governana era descobrir para quem o PMO respondia. Por
enquanto reportava-se a Steinberg como Diretor de Desenvolvimento de Aplicativos, o que na
opinio dele ocorria por causa da sua experincia com metodologias e padres. E explicou algumas
das opes de governana:
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
incio ao processo. Acho que no futuro deveria reportar-se a outra pessoa se no for o CIO, a
alguma outra pessoa na organizao... Possivelmente reportar-se ao vice-presidente snior ou,
se montarmos o tal Planning Office, ento talvez fosse ao Planning Office.
Strider reconhecia que o modelo atual de governana era apenas temporrio e disse o que achava:
A nica razo para estabelecermos um PMO porque existe um Planning Office para a
companhia e o vice-presidente snior est comprometido com uma abordagem mais planejada
e rigorosa de gerenciamento de projetos. No 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 no
tenho tempo agora... Existe tambm o Planning Office que no sereporta a mim, mas ao vicepresidente snior e essa uma possibilidade.
Ao entender esta estreita interao entre o novo Planning Office e o PMO, Steinberg compartilhou
sua preocupao sobre o PMO permanecer dentro da TI:
Acho que enquanto se mantiver como uma diviso parte dentro de TI, continuar a
questo ns e eles e permanecer o sentimento de que estamos fazendo do nosso jeito para
parecer bem. Participamos em vrias implementaes exitosas em grupo e queremos participar
em outras. Meu desejo avanar com o PMO, demonstrar os seus benefcios e assim
influenciar positivamente as outras reas.

Decidindo o melhor caminho a seguir

A indstria de PCs estava mudando e a AtekPC enfrentava fortes presses de grandes
competidores como a HP, Dell e Lenovo. Para competir num setor em transformao, no qual
ocorriam fuses, a AtekPC havia implementado um Planning Office corporativo. Ao reconhecer o
papel que a TI certamente teria de preparar a AtekPC para responder s presses do setor, o vice
presidente snior apoiou a criao 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
possvel que o PMO fracassasse devido ao desafio de implementar uma proposta para projetos
disciplinadora e com base em medies, num ambiente onde isto era visto como estranho cultura.
No final das contas, a AtekPC era uma organizao acostumada a pessoas se virando, fazendo tudo
que precisasse para fabricar e entregar seus produtos diariamente.
12
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 Escritrio de Projeto da AtekPC

313-P02

A implementao do PMO j tinha levantado vrios problemas, alguns dos quais tinham
demonstrado serem polmicos demais para serem resolvidos imediatamente. Na iniciativa PMO, a
AtekPC se adaptava medida que as coisas aconteciam. Quando tentavam resolver problemas
bsicos do PMO, todos na organizao 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 decises e seus esforos e isto era motivo de preocupao a todos.
O trfego parara quando Strider dirigia pela InterEstadual, tentando sair de Metrpolis e chegar a
casa naquela noite. Teve tempo para refletir novamente sobre o PMO. Conduzira a sua equipe
gerencial para esta estratgia de implantao e estava bem convencido de que o modelo PMO-light
deveria ser o escolhido. Tinha segurado a contratao de mais empregados em tempo integral para o
PMO. E estava preocupado com muitas questes que a implementao do PMO j tinha levantado.
Ser que dando pequenos passos e alcanar pequenos sucessos, conseguiria entregar o trabalho
rpido o suficiente? E pensou consigo mesmo enquanto esperava o trnsito 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 invs de montar um grande PMO e dizer, Aqui est o
meu PMO.

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

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.

Steven Gardner

Gerente Fabricao de
Sistemas

Richard Steinberg

Diretor de Desenvolvimento
de Aplicao

Analista Lder

Analista Lder

Analista Lder

Analista Lder

Linda Starr

Analista Lder

Gerente de Sistemas
Financeiros

John Strider

Chief Information
Officer

Organograma da AtekPC Information Technology

Gerente de Vendas de
Sistemas

Figura 1

Mark Nelson

Diretor PMO

Larry Field

Diretor Grupo Suporte

Gesto de Projetos

Gerente de Projeto

Gerente de Projeto

Gerente Grupo de
Trabalho Comunicaes

Diretor de Operaes
& Tecnologia

Gerente Reposio
Sistemas Avanados

313-P02

-14-

O Escritrio de Projeto da AtekPC

Figura 2

313-P02

Formulrio de Ideias da AtekPC

FORMULRIO DE DESENVOLVIMENTO DE IDEIA

Seo A. (Solicitante preenche essa seo)
Nome do Solicitante:
Data Submisso da Solicitao:
Nome do Sistema (se conhecido):
Necessrio para Data:

Nome do Projeto:

Seo B.
(Revisor preenche essa seo)

Aprovado
Revisor da Ideia:
Data de Reviso:
ID do Projeto:

Reprovado - Razo para reprovao:

Seo C. Tipo de Trabalho (Revisor preenche essa seo)

Melhoria

Emergncia

Correo

Seo D. (Solicitante preenche essa seo)

1. Faa uma Descrio (O que ):

2. Por que devemos fazer isso? (Explique o valor de negcio e selecione o tipo de benefcio apropriado)
Explicao:
Tipo de Benefcio (mas de um tipo pode ser aplicado) Estime se possvel
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 mudanas, nova tela, entrada de dados, etc...)

5. Departamentos/Clientes Impactados

6. Premissas

7. Projetos relacionados

8. Risco/Impacto de no fazer o projeto

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