308-049 O Escritrio de Gerenciamento de Projetos AtekPC

F. WARREN MCFARLAN
MARK KEIL
JOHN HUPP
1



O escritrio de gerenciamento de projetos AtekPC

Comeou a chover cedo no incio da tarde de 3 de maro de 2007, e as
ruas de Metropolis eram frias e cinzas no local da sede da AtekPC. Enquanto
John Strider, Diretor de Informtica da AtekPC, arrumava sua pasta no fim do
dia, seus pensamentos se voltaram para o novo Escritrio de Gerenciamento
de Projetos (PMO), aprovado por ele alguns meses atrs. Durante sua estada
de quase vinte anos na AtekPC, Strider nunca testemunhou os tipos de
presso que a indstria de computadores pessoais (PC) sofria agora. Strider
reconheceu que a indstria passava por uma transio e que sua organizao
de Tecnologia da Informao (TI) se envolveria em projetos de importncia
central nos prximos dias, j que a AtekPC pretende assumir um papel de
liderana em tais mudanas. Foi este pensamento que o fez lembrar da
iniciativa PMO. Se ela fosse implementada de modo correto, a PMO poderia
ser uma grande ajuda para a AtekPC, mas Strider possua preocupaes sobre
o que poderia acontecer caso eles tentassem forar esta ideia. Ao invs de
ajudar, ela poderia se tornar outro item na lista crescente de problemas. Havia
muitas questes em sua cabea:

Qual a quantidade de GP suficiente? Qual a quantidade de apoio PMO
suficiente? Quando voc chega ao ponto em que a estrutura e o processo PMO
permitem a produtividade e contribuem para um resultado mais bem sucedido
com poucos erros e maior qualidade de resultado independente de como
defina sucesso no incio? E quando o envolvimento GP se torna administrao
para seus prprios propsitos? Quando se cruza a linha?

Strider pensou que compreendia o que este PMO poderia fazer pela
AtekPC, mas a iniciativa ainda estava no incio. Precisava de tempo para se
firmar. Por um lado, sua equipe administrativa contratou pessoas experientes
com um talento real para guiar o programa PMO. Por outro lado, eles eram
novos no mercado de PC e na AtekPC. Eles no entendiam o verdadeiro poder
da cultura ali, pensou. Como Strider expressou, o PMO havia se tornado parte
da cultura AtekPC, e isso exigia pequenas mudanas por um longo perodo de
tempo. Se o PMO se visse lutando contra a cultura, ele definitivamente falharia.
Como diretor de informtica, ele estava ciente das muitas iniciativas e
responsabilidades que teria de cobrir com seus recursos limitados, e sabia que

1
O professor F. Warren McFralan, o Professor Mark Keil da Georgia State University e John Hipp (MSIS
2007) prepararam este caso. Certos detalhes foram disfarados. Casos HBS so desenvolvidos apenas
para discusso em sala. Os casos no tm o objetivo de servir como endosso, fontes ou dados
primrios, ou ilustraes de gerenciamento eficiente ou ineficiente.
Copyright 2007 reitor e Colegas da Harvard College. Para solicitar cpias ou permisses para
reproduzir estes materiais, liguem para 1-800-545-7685, escreva para Harvard Business School
Publishing, Boston, MA 02163, ou v para HTTP://www.hbsp.havard.edu. Nenhuma parte desta
publicao poder ser reproduzida, armazenada em um sistema de recuperao, usada em planilhas ou
transmitidas de qualquer forma ou por qualquer meio-eletrnico, mecnico, fotocpia, gravao, ou
similares sem permisso da Harvard Business School.
308-049 O Escritrio de Gerenciamento de Projetos AtekPC
o PMO era apenas um deles. Ele no podia abandonar outros apenas para
desenvolver este novo PMO. Tudo deveria ser feito em conjunto. Strider sabia
que as pessoas trabalhando no PMO estavam frustradas por no poder
trabalhar mais rpido. Ele tambm estava tentado pelo pensamento de dar
mais recursos para o PMO e cancelar outros projetos. Mas, em sua opinio,
isso seria uma iniciativa audaz e de curta durao - muita coisa, muito cedo e
muito rpido.
Strider fechou sua pasta e se dirigiu para o elevador. Sua equipe snior
de gerenciamento de TI estava com ele h muitos anos. Ele sentia confiana
que poderia lider-los no caminho correto sem esfriar o entusiasmo com este
novo PMO. Mas isso seria suficiente? Para Strider, a recompensa era o
alinhamento alinhamento de direes estratgicas de negcios com recursos
TI, e essa era a essncia do PMO. Havia pequena margem para erros na
AtekPC nessa poca de mudanas.

Formao da Indstria

A indstria de informtica passava por srias presses sobre custos e
passava por um perodo de consolidao. Com as quedas das margens de
lucros, os fabricantes de computadores iniciavam estratgias de reduo de
custo voltadas para a melhora da eficincia de suas cadeias de suprimentos,
ao mesmo tempo em que reduziam o custo da distribuio. De acordo com um
artigo recente de jornal:

Os ltimos resultados financeiros dos fabricantes de computadores
mostram uma reduo nas vendas e na lucrabilidade. Tanto as empresas
quanto os consumidores esto ficando com seus computadores por mais tempo
para evitar custos e as complicaes relacionadas com a atualizao de seus
equipamentos. Como consequncia, as compras esto sendo adiadas e os
fabricantes procuram novos mercados para oportunidades de crescimento. A
indstria parece passar por uma onda de consolidao conforme o controle de
custos e a escala se tornam mais importantes do que nunca.
2


Em 2007, as principais revistas apresentavam artigos de capas com o
ttulo Definham os Computadores? As ameaas relatadas em suas anlises
eram mundiais e apresentavam uma variedade de fatores, incluindo a
popularidade crescente de telefones celulares, PDAs e software de aplicao
baseada na internet.

Para a maioria das pessoas, o e-mail o aplicativo de uso mais importante.
Por um grande perodo de tempo, para enviar e receber e-mails era necessrio
ter um computador completo. Entretanto, hoje em dia, empresrios e
consumidores querem colher os benefcios de ser capazes de acessar o e-mail
de qualquer lugar, 24 horas por dia, sem a inconvenincia de ficar carregando
um notebook por todos os lados. Hoje, telefones celulares e PDAs oferecem
esta funcionalidade, fazendo com que muitas pessoas questionem a
necessidade de transportar um computador. Nos dias da exploso do
computador, o mercado era vasto, mas o crescimento desacelerou
consideravelmente. Mais alm, com a popularidade crescente de aplicaes

2
Smith, Davis PC Makers face increased price competition and industry consolidation, Metropolitan
News Journal, 17 de fevereiro de 2007, p.B7.
308-049 O Escritrio de Gerenciamento de Projetos AtekPC
baseadas na internet, tanto empresrios quanto consumidores compram cada
vez mais mquinas mais baratas que podem acessar e executar aplicaes
baseadas na internet e no precisam de grande capacidade de processamento
local ou de armazenamento. Tendo ignorado a realidade por anos, os
fabricantes de computadores finalmente esto fazendo algo. Para cortar custos,
eles j esto aprimorando suas operaes por meio do uso de tecnologia da
informao e buscam novos produtos e mercados para manter o crescimento
da receita e aumentar a lucrabilidade.3

AtekPC

Fundada em 1984, a AtekPC cresceu para se tornar um fabricante de
computadores de mdio porte nos EUA, tendo em 2006 vendas de $1,9 bilho.
A AtekPC empregava 2.100 funcionrios plenos e mais 200 de meio perodo.
Apesar da histria de rpido crescimento nos anos 1990, a AtekPC se viu
lutando junto de outros fabricantes de computadores pelo mundo enquanto
passavam pela transio de uma indstria em crescimento para uma indstria
madura. Strider explicou:

A indstria dos computadores mudou e continua a mudar em passo
acelerado. Em determinado ponto, a indstria dos computadores se aproveitou
de grandes taxas de crescimento e de boas margens de lucro. Como
consequncia, ns tendemos a no ser to cuidadosos como deveramos ter
sido em relao ao controle de custos e a como lidar com ameaas
competitivas. Agora, claro, a situao mudou e nos deparamos com uma
competio crescente de fabricantes asiticos de computadores que fizeram a
transio de fabricao por contrato para a produo sua prpria marca.

A indstria dos computadores passa por uma consolidao conforme
grandes participantes adquirem os menores para obter maior escala. Deste
modo, este o pano de fundo de nossa indstria hoje. Ns possumos uma
necessidade maior do que nunca de sermos agressivos e nos movermos
rapidamente, de modo que possamos reduzir custos e obter novos mercados.
Ns precisamos nos tornar uma empresa mais gil de modo que nossas
capacidades sejam mais consistentes com o que nosso nome significa. No
futuro, ns tambm teremos de nos especializar mais em relao ao nosso uso
de TI ou correremos o risco de nos tornarmos no lucrativos ou um alvo para
uma incorporao agressiva.

No outono de 2006, a AtekPC j havia iniciado diversas iniciativas e
projetado o posicionamento da organizao para o futuro. Uma dessas
iniciativas foi a criao do Escritrio de Planejamento Estratgico, cuja
responsabilidade era propor mudanas de negcios. Sob a orientao do
Escritrio de Planejamento Estratgico, o esforo PMO inicial que era focado
em projetos de TI um dia se tornaria uma iniciativa PMO. A AtekPC reconheceu
que eles precisariam ser capazes de gerenciar projetos de modo mais eficiente
e efetivo para que as propostas do Escritrio de Planejamento tivessem
sucesso. Em maro de 2007, o Escritrio de Planejamento Estratgico e o
PMO inicial estavam em operao h apenas alguns meses. De acordo com
Strider, a AtekPC passava por uma competio crescente sobre o preo e a

3
Whither the PC?, Global News, 20 de maro de 2007, p;9
308-049 O Escritrio de Gerenciamento de Projetos AtekPC
administrao sofria grande presso para garantir que cada ao tivesse um
retorno visvel.

Tecnologia da informao na AtekPC

Com o passar dos anos, a AtekPC desenvolveu um amplo portflio de
aplicaes. Estas aplicaes eram focadas principalmente no nvel operacional
para funes comerciais tpicas de um fabricante de computadores, como
contabilidade, fornecimento, produo, vendas e distribuio. A integrao de
arquitetura destes sistemas de aplicao era obtida apenas moderadamente,
de modo que em 2007, as reas funcionais recebiam frequentemente servios
discretos de informao com pequena integrao entre funes. Projetos de
sistemas de informao eram normalmente esforos operacionais ou de
manuteno feitos sob solicitao de determinada rea funcional. Eles
costumavam ser projetos pequenos e de mdio porte em relao ao tamanho e
a durao, e eram administrados informalmente sem prticas padronizadas.
Como o Diretor de Desenvolvimento de Aplicao, Richard Steinberg explicou:

Historicamente, ns sempre cuidamos de nossos prprios assuntos. Ns
tivemos diversos projetos operacionais e vrias melhorias acontecendo, mas
tivemos poucas aplicaes de negcios... Com o passar dos anos, certas
pessoas na empresa reconheceram que a qualidade do trabalho feito nos
projetos poderia ser melhorada. Conforme comeamos a observar o que era
necessrio fazer no futuro, percebemos que tnhamos mesmo que aperfeioar
nossas habilidades para sermos capazes de nos mover mais agressivamente e
com firmeza pelos projetos e para sermos capazes de lidar com diversos
projetos de cada vez. Ento, iniciei um plano para um PMO, basicamente uma
metodologia de gerenciamento de projetos para todas as minhas reas.

O ambiente de mudana por qual passava a AtekPC criou diversos desafios
que eles planejavam abordar com projetos de escala grande e complexa. O
novo PMO estava sendo apresentado para fornecer a padronizao no
gerenciamento destes projetos e para obter melhorias no planejamento e no
desempenho das iniciativas. Apesar de a AtekPC ter participado de alguns
projetos grandes no passado que empregavam algumas prticas formais, estes
projetos no resultaram na formalizao duradoura das prticas. Steinberg
explicou:

Se voltar alguns anos, para Y2K, para a converso de nosso sistema de
gerenciamento de ordem; nos maiores projetos, eles usaram uma abordagem
de gerenciamento de projetos. Eles no perceberam. Eles reuniram todos,
conversaram sobre o era necessrio ser feito, e o fizeram. Todos distriburam
elogios e disseram foi bem feito. Agora que terminamos, devemos voltar a
fazer projetos normalmente. Eles no perceberam esse era o modo de se
trabalhar. De repente todas as preocupaes maiores desapareceram, quando
elas desaparecem, voc tenta fazer novamente como antes.

Em 2007, projetos de TI costumavam ser gerenciados ao se incluir
responsabilidades de GP para algum da equipe de desenvolvimento que era
responsvel por determinada rea funcional. Por exemplo, o analista Chefe
responsvel pela Produo tambm teria a funo de gerente de projetos. O
analista Chefe supervisionava grupos de trabalhos de analistas e
308-049 O Escritrio de Gerenciamento de Projetos AtekPC
programadores de vrios nveis diferentes de habilidade e eram responsveis
por satisfazer as solicitaes das reas funcionais e pelo desempenho de seus
grupos de trabalho. Usando um processo informal de iniciao de projeto, os
usurios solicitavam servios de TI por meio do Analista Chefe que gerenciava
os projetos com o apoio de recursos em seus grupos de trabalho. O gerente,
neste caso de Gerente de Sistemas de Produo, resolvia quaisquer
problemas e conflitos, se necessrio; de outra maneira, a solicitao era
recebida, executada e entregue por meio do Analista chefe. Mtodos de
Projeto, documentao, prticas e ferramentas eram individualizados pelo
analista Chefe com pouca ou nenhuma consistncia pelos grupos de TI ou
reas comerciais.

A AtekPC percebeu os muitos benefcios desta abordagem informal para
os projetos. Analistas Chefes frequentemente passam mais tempo em suas
reas e desenvolvem um conhecimento aprofundado das atividades
comerciais, necessidades e pessoas. Como consequncia de sua abordagem
informal, eles forneceram uma resposta rpida para solicitaes de usurios e
foram capazes de equilibrar necessidades crticas emergentes em seus grupos
de trabalho com alguns conflitos. Por causa deste histrico de entrega
responsiva, foi depositada confiana considervel entre a rea funcional e seu
Analista Chefe. O relacionamento baseado em confiana foi altamente
personalizado para os funcionrios como indivduos, e as lealdades surgiram
em ambos os lados. A abertura destes relacionamentos permitiu que o analista
Chefe juntasse e avaliasse rapidamente os requisitos para obter um consenso
sobre cronograma e data entrega. Linda Star, uma analista Chefe da Produo,
descreveu seu trabalho nesta funo:

Em meu mundo, tenho uma variedade de usurios com quem converso.
Eles costumam dizer: Preciso disso. Alguns diriam: Preciso muito disso.
Posso pegar? uma emergncia e preciso disso. Eu me virava, olhava para o
que as pessoas estavam trabalhando e dizia: Eu preciso que voc troque a
pea. D-me duas horas, dois dias ou o quanto for necessrio. Ns precisamos
fazer essa pequena pea... Eu fao um cronograma baseado no que todos em
meu grupo esto fazendo e o que eu sei aps falar com ele.

Esta abordagem informal ao gerenciamento de projetos costumava ser a
norma na AtekPC. Historicamente, a viso prevalecente era a de que a TI era
perifrica s atividades comerciais principais da AtekPC. Como consequncia,
a TI era vista como uma recebedora de ordens, esperada a prestar servios
sob demanda. Durante a ltima dcada, os projetos se tornaram cada vez mais
focados em operaes e manuteno em um grande esforo para melhorar a
eficincia nas funes comerciais. O desenvolvimento de sistemas de
integrao entre funes e o uso de tecnologias de internet eram apenas duas
necessidades emergentes conforme a AtekPC lutava com mudanas radicais
em sua indstria e mercado. Os novos projetos exigidos eram maiores, mais
complexos e envolviam diversas reas funcionais e tecnolgicas, diferente dos
projetos altamente focados executados no passado por um nico grupo de
trabalho. Esperava-se que as demandas destas novas iniciativas e projetos
sobrecarregassem os mtodos correntes informais de gerenciamento de
projetos. O PMO da AtekPC estava sendo implementado para oferecer mais
consistncia e melhores prticas para projetos comerciais e de IT. Entretanto,
308-049 O Escritrio de Gerenciamento de Projetos AtekPC
implementar um PMO na AtekPC por si s era um desafio que necessitava de
um gerenciamento habilidoso para ter sucesso. Um difcil equilbrio deve ser
mantido entre a manuteno e o novo desenvolvimento, assim como entre os
recursos que iam para atividades de desenvolvimento contra os recursos que
iam para atividades de administrao de projetos sob o novo PMO. Strider
descreveu o desafio:

Ns ainda no entendemos tudo. melhor do que achar que sabe quando,
na verdade, no sabe. No departamento de TI, ns temos de ser mais capazes
de administrar conflitos entre novas iniciativas comerciais crticas e operaes
com mudanas incrementais aos sistemas existentes. Ns no podemos
sacrificar um pelo outro. A histria que fazamos apenas manuteno
operacional e agora temos a cultura de fazer ambas.

Misso do PMO

A misso do PMO da AtekPC foi evoluindo gradualmente desde sua
criao no final de 2006. Desde a primavera de 2007, no houve um consenso
sobre seu objetivo, suas responsabilidades e sua autoridade. Enquanto a
documentao formal e os planos para o PMO no existiam, o objetivo
imediato era estabelecer o escritrio e provar seu valor. O consenso geral era
de que o PMO era para executar os benefcios derivados de prticas
consistentes de projetos. Apesar de no especificar de modo claro ou
mensurvel neste momento, esses benefcios eram expressos em uma
variedade de termos, variando de melhorias de TI em desempenho de projeto,
eficincia e utilizao de recursos para de melhorias comerciais em
gerenciamento de custo e capacidade corporativa para criar produtos.
Steinberg explicou sob a perspectiva da empresa:

Quando penso na indstria do computador e em seus desafios, penso em
duas coisas que podem estar se dirigindo a um PMO. Uma pode ser a reduo
de custos. No podemos nos dar o luxo de sermos descuidados. Sinceramente,
devemos ser muito mais cuidadosos no modo em que usamos nossos
recursos. Outra motivao para melhorar os projetos seria nos tornarmos mais
criativos, adaptativos, geis no lanamento de novos produtos. E para lanar
novos produtos, o que voc diria que est guiando estas iniciativas alm do
gerenciamento de projetos?

Entretanto, as responsabilidades do PMO no eram to claras. No momento as
responsabilidades do PMO eram limitadas a projetos de TI, apesar de haver
uma discusso sobre expandir seu escopo para um PMO de nvel empresarial
que, no futuro, incluiria projetos comerciais. Os deveres especficos de um
PMO costumavam ser divididos em duas categorias: focado no projeto e
orientado para a empresa. Responsabilidades focadas no projeto como
consultoria, tutoria e treinamento eram servios que permitiam o sucesso de
projetos individuais. Por outro lado, responsabilidades comerciais voltadas a
servios que podiam melhorar todos os projetos como gerenciamento de
portflio, padres de GP, mtodos e ferramentas e arquivos de desempenho de
projeto. O esclarecimento das responsabilidades do PMO evolua
continuamente conforme a AtekPC tentava obter apoio para chegar a um
acordo em sua misso e constituio:
308-049 O Escritrio de Gerenciamento de Projetos AtekPC

Na AtekPC, responsabilidades focadas no projeto eram meios iniciais
usados para provar mritos de seus PMO. O plano era criar aceitao ao
consultar e fazer tutoria para projetos individuais. Mark Nelson, o novo Gerente
PMO, falou sobre este esforo:

O que fazemos desde outubro de 2006 tem sido fornecer tutoria e apoio
para a administrao de projetos em seus projetos principais que foram
identificados por executivos de TI. Para o futuro imediato, at entrarmos em
funcionamento, o plano fazer com que eu trabalhe com uma pessoa em um
ponto de vista de planejamento de projeto reunies regulares com as
equipes, relatrio de situao, questes de manuteno e riscos de
gerenciamento.

No final, o PMO continuou a receber apoio das reas funcionais e de
funcionrios de TI relacionados com estes projetos. Uma das maiores
limitaes era a escassez de recursos experientes em PMO disponveis para
apoiar tais projetos. Complementando Nelson, havia outros trs gerentes de
projeto atribudos para o PMO e eles eram funcionrios contratados. Usar a
equipe PMO para gerenciar diretamente os projetos era feito com pouca
frequncia, entretanto, Nelson tinha designado um de seus gerentes de projeto
para projetos crticos relacionados ao lanamento de um novo notebook.

Responsabilidades voltadas para empresa para novos PMO foram lentas de se
desenvolver na AtekPC. O novo PMO esteve desenvolvendo alguns processos
e procedimentos padres de projetos. Steven Gardner, Gerentes de Produo
de Sistemas, comentou sobre um processo de criao de um projeto que o
PMO introduziu:

Nelson nos ajudou a desenvolver o que chamamos de formulrio de ideia,
onde ns tentamos eliminar diversas chamadas aleatrias que chegam para
ns. Ns tentamos priorizar melhor no que trabalhamos, e usar este formulrio
de ideia nos direciona na construo de uma compreenso de negcios de
onde a ideia surgir. Isso nos fora a pensar antes no nosso lado e no lado do
solicitante. Ajuda a eles a pensarem sobre o uso. Por que vamos obter
economia aqui? Qual o motivo para isso? Vale a pena fazer este projeto custa
de outro? Agora, como o priorizo? Deste modo, nos ajuda a colocar nossos
braos em torno do que estamos trabalhando.

Os servios focados na empresa desenvolvidos pela equipe PMO de
Nelson estavam sendo bem recebidos. Enquanto o avano nesta rea estava
sendo restrito pelos recursos limitados do PMO, houve um consenso claro,
mesmo no nvel do Diretor de Informtica, de que o PMO era responsvel por
estabelecer, publicar e disseminar prticas de projetos, padres e ferramentas.
Por outro lado, o gerenciamento de portflio (a mudana de gerenciar projetos
para estabelecer tcnicas para correntes contnuas de gerenciamento de
projetos) e o arquivamento de responsabilidades (o estabelecimento de
registros de arquivos de projetos para compartilhamento de conhecimento) no
estavam sendo abordadas. Nelson esperava ser capaz de incluir tais deveres
na misso conforme o PMO se desenvolvia, mas sem recursos adicionais, no
era possvel no curto prazo. Ele tambm percebeu que recursos adicionais s
seriam possveis sendo retirados de outras responsabilidades crticas, e isso
308-049 O Escritrio de Gerenciamento de Projetos AtekPC
poderia comprometer a capacidade de manter efetividade operacional. Era um
equilbrio desafiador.

A ltima rea de interesse em relao misso do PMO era a questo
da autoridade. Strider reconhecia que a aplicao destas novas prticas de
projeto exigia uma autoridade formal, e ele estava preparado para fornec-la
apenas quando o PMO tivesse se provado em negcios e TI. Nos esforos
iniciais de desenvolvimento, Nelson trabalhava sob o benefcio de uma
autoridade implcita que vinha de um reconhecimento geral das mudanas de
direo da administrao. Entretanto, o PMO tambm teve o apoio do vice-
presidente snior. Larry Field, diretor do Grupo de Apoio de Gerenciamento de
Projetos, era um membro principal da iniciativa PMO desde o seu incio e
explicou: para ns sermos eficientes, devemos ter apoio vindo de cima. E
tivemos tal apoio do vice-presidente snior, de John Strider e assim por diante.
Esta a coisa mais importante para o funcionamento da empreitada.

Entretanto, como nem todos os executivos seniores estavam igualmente
entusiasmados com o conceito de PMO, a autoridade foi inicialmente
desenvolvida de baixo para cima por meio da valorizao dos servios PMO.
Mesmo estes eram limitados a tais reas funcionais e s reas de TI
envolvidas no PMO. Atualmente no h planos para ampliar o uso em nvel
empresarial. Nelson resumiu esta abordagem com as seguintes observaes:

O mais importante a tutoria que est ocorrendo e realmente gerenciando
os projetos. Ns estamos sendo pacientes de modo que podemos obter alguns
bons exemplos concretos que podemos mostrar a eles. Ns podemos dizer
Olha o que isto est fazendo para voc. Este projeto que seria feito em um ano
e meio antes est sendo feito em trs ou quatro meses porque acertamos estas
prticas E isso essencial porque nos permite mostrar nosso valor. Essa deve
ser a abordagem por enquanto.

Organizao PMO

Dois modelos organizacionais foram levados em considerao para o PMO.
Eles eram conhecidos como PMO-pesado e PMO-leve, e representavam dois
extremos de um espectro de abordagens PMO. Em um extremo, o PMO-
pesado era caracterizado por uma equipe completa de gerentes de projeto que
assumiram a responsabilidade de administrar todos os projetos de TI. Este
modelo se concentrava na aquisio de especialistas em gerenciamento de
projeto, sejam fontes internas ou externas, e os usavam para gerenciar projetos
sob a direo do PMO. Na verso extrema do PMO-pesado, nenhum projeto
seria operado fora do gerenciamento e do controle direto do PMO. Este modelo
se concentrava no desenvolvimento de tcnicas de gerentes de projetos
internos que no eram formalmente relacionados com o PMO. Na verso
extrema do PMO-leve, todos os projetos operados fora do PMO sob controles
organizacionais existentes, e a propriedade dos projetos residia na rea
funcional e no grupo de TI responsvel pela execuo do projeto. A questo
onde o PMO deveria se localizar no espectro do PMO-pesado para o leve
gerava vrias discusses e pouco s acordos. Strider falou sobre esta
controvrsia:

308-049 O Escritrio de Gerenciamento de Projetos AtekPC
Neste momento, so quatro pessoas em tempo integral... Dada a
velocidade em que ns, como empresa, desejamos nos mover ns, como
uma empresa, precisamos nos mover acho que quatro pessoas permanentes
muito pouco. Vejo essas pessoas relacionadas a projetos maiores para
auxiliar, mas a diversidade de aplicao muito ampla. No vejo todo o
gerenciamento sendo entregue para este grupo. H uma diferena de opinio
entre mim e o PMO sobre o assunto neste momento. Ns teremos que
descobrir um meio termo... Estou convencido que deve ser leve. Isso no
significa que eu no o questiono, por que h muitas pessoas neste
departamento que me contestam frequentemente sobre o assunto. O que est
tudo bem, quero dizer, no preciso que fiquem concordando comigo o tempo
todo.

Enquanto Nelson concordava em trabalhar com uma equipe pequena no
incio, ele sentia que os atrasos desta abordagem podiam comprometer a
capacidade de fornecer servios PMO e de demonstrar seu valor para as reas
funcionais do negcio. Entretanto, ele e outros gerentes reconheceram que os
recursos no eram gratuitos, e que eles vinham de algum lugar, o que
significava reduzir as capacidades do trabalho de outras pessoas para avanar
seu prprio. Strider lutou com este desafio e os quatro recursos PMO atuais
foram obtidos em detrimento de outras equipes operacionais. Mesmo enquanto
Nelson trabalhava com estas limitaes, ele esperava obter mais ajuda,
conforme ele explicou:

Caso no houvesse restries, eu gostaria de ser capaz de trazer uma
equipe de pessoas, consistindo de analistas de projetos e de gerentes,
rapidamente. Trazer um grupo de pessoas antecipadamente. A maioria deles
seria nova para comear. Mas com o passar do tempo, seria possvel chamar
gente da prpria empresa. Eles fariam parte do PMO. Deste modo teramos
vrios graus de experincia variando de GP seniores a juniores.
Conseguiramos muito apenas com esta etapa.

Steinberg estava preocupado com os recursos necessrios e em como
as reas funcionais poderiam responder ao se adicionar mais pessoas neste
momento. Ele explicou: Qual a implicao de um patrocinador em Vendas
tentando iniciar um projeto que tem aprovao do PMO? Eles no entendem
literalmente o que o PMO. Eles acham que um bloqueio e um obstculo ao
avano algo burocrtico.
A preocupao de Steinberg sobre como as pessoas poderiam ver o
PMO foi compartilhada por Strider. Apesar de Strider estar convencido de que
o PMO era o melhor modo de agir para a AtekPC, ele sabia que tambm tinha
que garantir que a TI mantivesse se equilbrio e fizesse o trabalho. Como
Strider explicou:

Agora, se voc adicionar pessoas, onde voc as inclui? O fato de voc
poder adicion-las um avano. Voc as adiciona neste PMO, ou voc as
adiciona em outro lugar? ... A questo como voc faz para ir aonde precisa,
mas sem violar a cultura de modo a gerar uma grande confuso... Porque o
PMO no pode fazer os projetos. Eles no vo escrever o cdigo, eles no vo
instalar os servidores; eles no vo se encontrar com os usurios que
entendem os requisitos funcionais; eles no vo se encontrar com os clientes.

308-049 O Escritrio de Gerenciamento de Projetos AtekPC
Na linha de frente, Star estava obtendo algumas informaes por meio
de boatos sobre este novo PMO, e ela tentou entender o que estava
escutando, de modo que estivesse pronta para se adaptar a quaisquer novas
mudanas. Ela certamente estava esperando por mais ajuda, ela tinha de lidar
com vrios problemas de administrao de projetos, e estava ciente da
oportunidade que o PMO criou para ela. Ela estava ansiosa para aprender a
ser mais eficiente como gerente de projeto, mas no tinha certeza do que
estava realmente acontecendo. Ela descreveu sua compreenso sobre o PMO:

Pensei que seria uma grande ideia porque pensava que seria um grupo que
lideraria projetos diferentes, e seriam os principais gerentes de projetos. E ns
seramos sua equipe. Eu estava pensando que eu ainda seria a pessoa
responsvel o lder - por tal projeto, pelo grupo com quem estava
trabalhando. Mas seria, essencialmente, responder para este gerente de
projeto que possua as habilidades e o conhecimento e o treinamento e todas
as ferramentas para nos ajudar a avanar. Isso ocorria porque histrico em
gerenciamentos de projeto um processo e ferramentas que eu mesma criei
para criar, analisar e manter registros. Ento pensei que eles viriam com estas
ferramentas e, em breve, estariam nos ensinando; e em breve nos tornaramos
gerentes de projetos por conta prpria.

Gerente de Star, Gardner tinha a expectativa de que o modelo PMO
seria mais pesado do que leve. Ele j estava convencido dos mritos do PMO
do uso da forma de ideia de seu grupo para obter solicitaes de novos
projetos. Em sua compreenso, o PMO forneceria uma rede de recursos de
gerente de projeto. Ele falou sobre sua viso do modelo organizacional:

Eles esto saindo apenas de nos ajudar com tipos de metodologias para
gerenciar projetos... Eles pensam em uma rede de gerentes de projetos. Voc
pode ter determinado projeto, e pode pegar tal pessoa por um momento. E seu
projeto responderia a eles. Eu acho que a compreenso deles de terem
gerentes de projetos nos quais voc atribui os vrios projetos por
departamento. Por exemplo, ns estamos usando um agora para este novo
lanamento de projeto em adio aos projetos que temos agora. Ela vai
comear a assumir a funo de planejamento de linha de tempo, cronograma,
convocar as pessoas certas e garantir que todos estejam informados as
tpicas funes de gerentes de projeto... Em relao ao gerenciamento de
projetos, o projeto de sua responsabilidade. seu trabalho.

Na viso de Gardner, ele manteria o controle do projeto, e em sua
durao, o gerente de projeto da equipe do PMO seguiria suas instrues. Os
recursos seriam atribudos em uma estrutura de matriz pela durao do projeto.
Era isso que Gardner fazia com o gerente de projeto PMO atual que foi
atribudo para um de seus projetos, e na opinio de Gardner, isso era uma
grande ajuda porque ele tinha poucas pessoas e uma grande pilha de projetos
a serem feitos. Gardner esperava que o PMO fornecesse seu grupo com
gerentes de projetos de modo similar a um PMO-pesado.
Por outro lado, Field reconheceu que o problema da estrutura PMO no
era apenas sobre a equipe de TI,

O problema com um PMO-pesado no apenas levar os gerentes de
projetos e analistas. Tambm so os recursos empresariais. Hoje, ns temos
gerentes de linha que trabalham em diversos projetos alm de suas funes
308-049 O Escritrio de Gerenciamento de Projetos AtekPC
comuns, e eles no podem acumular ainda mais. O que realmente dirige vrios
projetos qualquer empresa a disponibilidade dos recursos de trabalharem em
tais projetos. Ter os recursos empresariais disponveis j est se tornando um
problema para ns. Com um PMO-leve, ns estamos melhores alinhados com
o lado empresarial em relao aos nmeros de recursos, e um equilbrio
melhor.

Nelson destacou o PMO-pesado como o melhor modelo para a AtekPC,
mas ele reconheceu que no seria capaz de obter a aceitao imediata por
esta abordagem. A demanda por recursos era grande na AtekPC, e o PMO
precisaria se provar para obter os recursos que queria. Ele pretendia obter
apoio para o modelo PMO-pesado por meio de sucesso em projetos. Conforme
o PMO ganhava aprovao, ele queria implementar uma abordagem PMO-
pesado, fornecendo gerentes de projetos para vrios grupos. Conforme disse:

No acho que saibam o suficiente sobre gerenciamento de projetos para
diferenciar entre o PMO-leve e o pesado. Algumas estruturas organizacionais
foram discutidas... mas devido a mudana geral por qual a empresa passava,
eles no estava prontos para tomar este tipo de deciso... com estes processos
e procedimentos que estamos desenvolvendo, ns vamos estabelecer
planejamento de projeto, acompanhamento, iniciao e encerramento. Todos
os gerentes de projeto ajudaro a organizar o TI.

Conforme a AtekPC lutava para encontrar o modelo organizacional
correto, a equipe PMO trabalhava para fornecer os servios que estavam
criando lentamente sua credibilidade e provando seu valor para a AtekPC.
Encontrar o local correto para o PMO no espectro entre os modelos
organizacionais pesado e leve era uma tenso constante que deveria ser
trabalhada cedo ou tarde. Com mais recursos, Nelson acreditava que sua
equipe poderia fornecer mais apoio mais rpido e se mover mais rapidamente
em projetos crticos e padro. Por outro lado, Strider lembro Nelson que o PMO
era uma das responsabilidades na organizao de TI da AtekPC. Haviam
outras necessidades de recursos em suas prprias justificativas e devolues.
Portanto, a questo do PMO-pesado contra o PMO-leve no era uma deciso
simples ou fcil.

Implementao e cultura

A AtekPC estava envolvida em um desafio difcil de tentar implementar
mtodos padro em uma empresa que no estava acostumada a processos e
padronizao consistentes e disciplinados. O gerenciamento de TI percebeu
que no futuro eles dependeriam de padres e processos consistentes para
administrar seus projetos e lev-los adiante. Independentemente, implementar
um PMO em um ambiente no-PM era desafiador porque ia contra a natureza
da cultura organizacional. Muitas pessoas na AtekPC viam o gerenciamento de
projetos como burocracia algo que inevitavelmente atrapalharia o modo de
fazer o trabalho real. Field descreveu o desafio cultural no caminho do novo
PMO:

Ns estamos mudando de uma empresa que no possua uma
administrao de projetos formais para uma empresa que gostaria de ser
308-049 O Escritrio de Gerenciamento de Projetos AtekPC
bastante formal. Ns seremos algo no meio. Ns no podemos ser rgidos
sobre o gerenciamento de projetos. Esta cultura no nos permitir a fazer isso.
Voc deve misturar a cultura com os mtodos e os processo e agora eu at
mesmo ouo onde o processo no pode ser to rgido. Se ficarmos muito
rgidos, ele falhar. Ns temos de ser um pouco fludos e dinmicos em
determinados momentos, e isso incomoda algumas pessoas do PMO, mas
temos que fazer desse modo aqui. Para obter sucesso, ns devemos
desenvolver uma organizao que ser flexvel e precisa neste relatrio. Esta
a minha luta fazer com que o gerenciamento de projetos caiba em uma
cultura que est mudando, mas que ainda no atingiu o nvel.

s vezes, para aqueles envolvidos, as foras de oposio ao PMO
parecem esmagadoras. Strider imaginava o quanto aberta prpria
organizao de TI estava em relao mudana de seus processos e de se
adaptar para novas prticas de gerenciamento de projetos. Essa era uma
questo cultural central em sua cabea. Muitas pessoas da equipe, incluindo
gerentes, tinham pouca ou nenhuma experincia com prticas formais de
gerenciamento de projeto. Muitos poucos sabiam como usar qualquer
ferramenta de software disponvel, como o Microsoft Project. Alm dessas
barreiras sobre o conhecimento, a informalidade das prticas atuais era vista
como muito atrativa. As reas funcionais gostavam de trabalhar com o pessoal
de TI que eram atenciosos com suas necessidades e resolviam tudo
rapidamente. A equipe de TI tambm achava a informalidade atraente, j que
os custos e o desempenho dos projetos no eram registrados. As reas
funcionais no eram responsveis por medir os benefcios resultantes de seus
projetos, e a equipe de projetos de TI no trabalhava com um oramento de
projeto pr-definido. Outra fonte de resistncia era a falta de compreenso nos
nveis de valores de gerenciamento de projetos formais. Juntos, estas fontes de
resistncia a um PMO criaram barreiras culturais formidveis para seu sucesso
e a equipe PMO tinha de lidar com elas.

Strider entendeu muitas destas barreiras culturais e reconheceu que
teria de encontrar modos de lidar com elas para que o PMO perdurasse. Em
uma discusso recente em volta de sua mesa, ele resumiu a situao: minha
opinio que tenho duas opes. Posso me conformar com a cultura e
sobreviver; ou posso lutar contra a cultura e falhar... Voc pode apenas seguir
o fluxo at certo ponto, independente de sua qualidade ou inteligncia. Mas se
voc sempre se opuser a cultura, voc perder.

No momento, a implementao estratgia do PMO na AtekPC era
trabalhar com a cultura e desenvolver foras que divulgariam o PMO e
superariam a resistncia cultural. Foras promocionais incluam tutoria,
aconselhamento e treinamento que estavam sendo fornecidos pela equipe
PMO. A empresa estava claramente sob presso para mudar o modo como
fazia negcios, mas no havia consenso entre os gerentes seniores em relao
o nvel de integralidade do PMO para alterar o processo. Na opinio de Strider,
eram muito cedo para se usar a autoridade formal sem provas de valor sem
amplo apoio para o conceito de PMO. Ele acreditava que primeiro era
necessrio mais comprometimento das reas funcionais. Uma das principais
questes culturais em sua cabea era com que velocidade as reas funcionais
(ou seja, os clientes de TI) estaria a se adaptar a um processo mais formal.
308-049 O Escritrio de Gerenciamento de Projetos AtekPC
Eles deveriam estar dispostos a priorizar projetos e a fazer escolhas difceis e
cesses. Em alguns casos, para avanar com um projeto, eles deveria estar
dispostos a ajudar a justificar recursos adicionais.

Nelson trabalhava para obter comprometimento das reas funcionais
usando sua equipe para auxiliar e dirigir gerenciamento de projetos para os
projetos principais. Ele reconheceu que esta estratgia de implementao era
um trabalho lento e exigia muita pacincia. Para ele, a luta era sobre criar e
fornecer um sucesso comprovado. Ele expressou o desafio conforme o via:

No posso chamar de cima para baixo (sua abordagem de implementao)
porque obtemos a aprovao de cima para que ns comessemos. Mas
como se fosse quase de cima, mas no exatamente l. visto como
burocrtico, ou como tendo potencial para ser burocrtico. E isso ocorre por
conta da prpria indstria e de seu passo- retire os produtos - pegue as ordens.
Uma das coisas que ouvimos vindo de cima No deixe este gerenciamento
de projetos e de processo atrasar tudo. Eles so timos, e queremos v-los
funcionando; mas no deixe que eles atrapalhem.

Como diretor de Desenvolvimento de Aplicaes, Steinberg foi um dos
primeiros apoiadores do PMO e ele viu algum avano ao se quebrar tais
barreiras culturais. Quando Steinberg chegou pela primeira vez na AtekPC, ele
recebeu a tarefa de implementar uma metodologia padro de desenvolvimento
de software. O esforo inicial para tal metodologia falhou, em sua opinio,
porque a cultura no era correta para uma abordagem disciplinada. Agora, ele
apoiava completamente este esforo de PMO, e ele trouxe uma compreenso
profunda sobre a cultura AtekPC e sobre seus desafios. Sob este ponto de
vista, apenas trabalhar com grupos de negcios um de cada vez poderia gerar
seu comprometimento com o PMO. Ele explicou sua abordagem:

A venda do PMO para fora da TI era um problema. Por mais que
tentssemos fazer com que tivesse visibilidade fora deste departamento, no
fui capaz de obter nenhuma visibilidade oficial. O que houve foi que tentamos
envolver nosso GP em projetos e os enviamos para os usurios relacionados.
Produo foi uma das primeiras reas. O representante do projeto TI em
Produo perguntou o que este PMO vai fazer? Quando contamos para ela,
ela se juntou a iniciativa. O mesmo aconteceu em Vendas.

Ele no foi bem recebido em certos grupos, mas, felizmente, foi em certas
reas... Produo j aceitou, Vendas est comeando a aceitar. Mas no tenho
certeza se as outras reas j esto aceitando este conceito.

Com algumas reas dando apoio, a equipe PMO continuou seus esforos de
implementao. Como Nelson comentou, seus avanos na poca tinha sido
passos de bebs. A frustrao com o progresso lento os tentava a usar outra
abordagem forar a mudana em mandatos de cima para baixo e contratar
especialistas. Diversos gerentes, incluindo aqueles diretamente relacionados
com o PMO, reconheceram a necessidade de uma equipe maior de
especialistas para criar padres e mtodos rapidamente, e eles defendiam uma
estratgia de implementao mais rpida e com intensidade de recursos. Tal
abordagem permitiria que o PMO provasse seu valor ao administrar ativamente
mais projetos e a ajudar a AtekPC a obter um desempenho de projeto melhor e
308-049 O Escritrio de Gerenciamento de Projetos AtekPC
mais consistente. A administrao de TI estava que tal abordagem falharia
porque no podiam forar uma mudana radical na AtekPC. Portanto os
gerentes seniores de TI encorajavam uma estratgia lenta e de incremento que
permitiria que o conceito de PMO se provasse com pequenas vitrias obtidas
tutorando um projeto de cada vez.

Governana

A questo da governana do PMO no havia sido amplamente discutida,
mas j possua certa importncia. No momento, no havia guias ou linhas de
tempo para sua maturao, ento, no havia modo de medir o desempenho
PMO alm do uso de opinies subjetivas daqueles relacionados. Havia uma
ideia de que a AtekPC saberia que o PMO estava funcionando porque os
projetos estavam sendo feitos e a empresa receberia o que era esperado. Field
reconheceu que haviam poucas medidas para projetos ou para o PMO. Ele
explicou:

Como nos avaliamos? Como uma organizao de projeto mede seu
sucesso? Umas das preocupaes era se os gerenciamento de projetos,
devido burocracia, iria atrasar os negcios. Ainda h preocupaes sobre
isso. Ns estamos tentando dizer que iremos acelerar as coisas e fazer tudo
mais rpido com menos retrabalho. Ento, como nos avaliamos para dizer que
estamos tendo sucesso? Ns realmente ainda no descobrimos tal mtrica.

Determinar como provar o valor do PMO era um grande desafio para
Nelson: Provar seu valor o nico modo de fazer tudo funcionar. E isso ser
difcil por que no havia muito registro de dados antes. Mas mesmo que no
seja muito preciso, podemos mostrar que... devemos ser capazes de mostrar
avano.
Dada esta abordagem para avaliao do desempenho PMO por meio de
consenso subjetivo e dados sem comprovao, a prxima questo da
governana era descobrir para quem o PMO responderia. No momento, ele
respondia para Steinberg como Diretor de Desenvolvimento de Aplicaes, o
que, em sua opinio, era devido sua experincia com metodologias e
padres. Ele explicou algumas opes atuais de governana:

Atualmente ele responde para mim no desenvolvimento de aplicao, mas
acredito que deveria ser para outro local... A verdade que fui colocado como a
pessoa para faz-lo funcionar. Acredito que em algum momento no futuro, seria
mais correto responder para outro departamento- se no para o Diretor de
informtica, para outro local na empresa... Acredito que haja uma possibilidade de
responder para o vice-presidente snior, ou se criarmos este novo Escritrio de
Planejamento, talvez para ele.

Strider reconheceu que o modelo atual de governana era apenas
temporrio, e explicou seus pontos de vista:

O nico motivo para estabelecermos um PMO porque existe um Escritrio de
Planejamento para a empresa, e o vice-presidente snior est comprometido com
uma abordagem de gerenciamento de projetos mais planejada e rigorosa. No
poderia lidar com isso internamente na TI a menos que tivesse apoio... Nesse
momento, ele responde para o chefe e Desenvolvimento de Aplicao. Steinberg e
308-049 O Escritrio de Gerenciamento de Projetos AtekPC
eu conversamos que, com o tempo, provavelmente, o PMO responder
diretamente para mim. Mas, sinceramente, agora no tenho tempo... Tambm h o
escritrio de Planejamento que no responde para mim, mas para o vice-
presidente snior, e essa uma possibilidade.

Entendendo esta interao prxima entre o novo Escritrio de
Planejamento e o PMO, Steinberg compartilhou sua preocupao sobre ele
permanecer na TI.

Acredito que enquanto permanea um elemento, uma diviso separada na TI,
sempre haver esta relao ns-eles, e o sentimento de que estamos l para
fazer do nosso jeito, nosso prprio trabalho e nossa funo o fazerele funcionar
melhor... Ns fizemos alguns trabalhos com aplicaes de grupo e tivemos
sucesso. As pessoas querem mais. Ento espero que eles tenham bastante
espao para iniciar o PMO e para mostrar os benefcios. Isso vender para as
outras reas e permitir que continue.

Decidindo o melhor modo de se avanar

A indstria da computao est mudando, e a AtekPC estava dedicada a
lidar com presses dramticas de competidores maiores, como HP, Dell e
Lenovo. Para competir com uma indstria em transformao na qual ocorria
consolidao, a AtekPC implementou um Escritrio de Planejamento
corporativo. Reconhecendo a funo que a TI teria de cumprir para permitir que
a AtekPC reagisse s presses da indstria, o vice-presidente snior apoiou a
criao do PMO na TI. A funo do PMO pode ser expandida para incluir
projetos fora da TI se o sucesso for comprovado. Ao mesmo tempo, havia uma
possibilidade de o PMO falhar devido ao desafio de se implementar uma
abordagem to medida e disciplinada para projetos em um ambiente visto
como estrangeiro para a cultura. Afinal, a AtekPC era uma empresa
acostumada a pessoas correndo todos os dias fazendo o necessrio para
produzir e enviar os produtos.
A criao do PMO j revelou diversas questes, algumas que se
provaram muito controversas para se resolver imediatamente. A AtekPC se
sentia seu caminho em direo ao PMO. Conforme tentavam criar um acordo
sobre questes bsicas do PMO, todos na organizao de TI estavam cientes
dos desafios que enfrentavam e o risco relacionado ao fracasso. Os projetos se
acumulavam rapidamente. O sucesso dependeria inteiramente da deciso e de
seus esforos, e esse era um motivo de preocupao para eles.
O trfego estava parado enquanto Strider dirigia pela interestadual,
tentando sair de Metropolis e voltar para sua famlia em casa naquela noite.
Isso deu tempo para que ele pensasse sobre o PMO. Ele havia guiado sua
equipe de gerenciamento para esta estratgia de implementao. Ele tinha
opinies fortes de que o modelo PMO-leve era o mais adequado. Ele evitava
contratar novos funcionrios plenos para o PMO. Ele estava preocupado com
quantas questes a implementao do PMO havia criado. Pequenos passos
construindo pequenos sucessos iam fazer o trabalho com velocidade o
suficiente? Ele pensou enquanto esperava o transito andar: como posso
chegar aonde preciso sem violar tanto a cultura, para que no gere um sinal
vermelho?... Acho que devo fazer do modo que estou fazendo em vez de
acumular um PMO grande e dizer aqui est o meu PMO.
308-049 O Escritrio de Gerenciamento de Projetos AtekPC


308-049 O Escritrio de Gerenciamento de Projetos AtekPC




















D
i
r
e
t
o
r

d
e

I
n
f
o
r
m

t
i
c
a

J
o
n

S
t
r
i
d
e
r

D
i
r
e
t
o
r

d
e

t
e
c
n
o
l
o
g
i
a
s


e

o
p
e
r
a

o

D
i
r
e
t
o
r

d
e

d
e
s
e
n
v
o
l
v
i
m
e
n
t
o

d
e

a
p
l
i
c
a

o

R
i
c
h
a
r
d

S
t
e
i
n
b
e
r
g

G
e
r
e
n
t
e

d
e

p
r
o
j
e
t
o
s

d
e

s
u
b
s
t
i
t
u
i

o

d
e

s
i
s
t
e
m
a
s

a
v
a
n

a
d
o
s

G
e
r
e
n
t
e

d
o

g
r
u
p
o

d
e

t
r
a
b
a
l
h
o

d
e

c
o
m
u
n
i
c
a

e
s

D
i
r
e
t
o
r

d
o

G
r
u
p
o

d
e

a
p
o
i
o

d
e

g
e
r
e
n
c
i
a
m
e
n
t
o

d
e

p
r
o
j
e
t
o
s

L
a
r
r
y

F
i
e
l
d

G
e
r
e
n
t
e

d
e

s
i
s
t
e
m
a
s

f
i
n
a
n
c
e
i
r
o
s

G
e
r
e
n
t
e

d
e

s
i
s
t
e
m
a
s

d
e

v
e
n
d
a
s

G
e
r
e
n
t
e

d
e

s
i
s
t
e
m
a
s

d
e

p
r
o
d
u

o

S
t
e
v
e
n

G
a
r
d
n
e
r

A
n
a
l
i
s
t
a

c
h
e
f
e

L
i
n
d
a

S
t
a
r
r

A
n
a
l
i
s
t
a

C
h
e
f
e

A
n
a
l
i
s
t
a

C
h
e
f
e


A
n
a
l
i
s
t
a

C
h
e
f
e


A
n
a
l
i
s
t
a

C
h
e
f
e


D
i
r
e
t
o
r

P
M
O

M
a
r
k

N
e
l
s
o
n

G
e
r
e
n
t
e

d
e

p
r
o
j
e
t
o

G
e
r
e
n
t
e

d
e

P
r
o
j
e
t
o

A
n
e
x
o

1
:

D
i
a
g
r
a
m
a

o
r
g
a
n
i
z
a
c
i
o
n
a
l

d
a

T
e
c
n
o
l
o
g
i
a

d
a

i
n
f
o
r
m
a

o

d
a

A
t
e
k
P
C

308-049 O Escritrio de Gerenciamento de Projetos AtekPC
Anexo 2: Formulrio Ideia AtekPC


FORMURIO DE DESENVOLVIMENTO IDEIA

Seo A. (Solicitante preenche esta seo) Nome do Projeto
Nome do solicitante:
Data de envio da solicitao:
Nome do sistema (se conhecido):
Necessrio at:
Seo B (revisor preenche esta seo)

Revisor Ideia:
Data de reviso:
Id do projeto

[ ] Aprovado

[ ] Reprovado motivo para no aprovao

Seo C. Tipo de trabalho (revisor preenche esta seo)


[ ] Melhoria [ ] Emergncia [ ] Conserto

Seo D. (Solicitante preenche esta seo)

1. Fornea uma descrio (o que ?):
2. Porque devemos fazer? (Explique o valor comercial e selecione o tipo de benefcio
adequado) Explicao:

Tipos de benefcios (mais de um tipo pode ser utilizado) Estime se possvel

[ ] Cria receita Receita anual estimada: __________
[ ] Evita custos Custos evitados estimados: __________
[ ] Economia de custos Custos anuais economizados: __________
[ ] Confiana operacional
[ ] Melhoria de atendimento ao cliente
[ ] Melhoria na qualidade

3. Escopo: (Descreva o que includo e excludo)
4. Resultados: (Mudanas de relatrios, tela nova, entrada de dados, etc...)
5. Departamentos / clientes afetados:
6. Dedues
7. Projetos relacionados
8. Risco/impacto de no executar o projeto

Fonte: AtekPC