Estudo de Caso 1

308-049 O Escritório de Gerenciamento de Projetos AtekPC

O uso deste documento é autorizado apenas para Antonio Luis Draque Penso da Universidade Estácio de Sá até Maio de 2014. Copiar ou divulgar é uma infração de direitos autorais. [email protected] ou 617.783.7860

F. WARREN MCFARLAN MARK KEIL JOHN HUPP

1

O escritório de gerenciamento de projetos AtekPC Começou a chover cedo no início da tarde de 3 de março de 2007, e as ruas de Metropolis eram frias e cinzas no local da sede da AtekPC. Enquanto John Strider, Diretor de Informática da AtekPC, arrumava sua pasta no fim do dia, seus pensamentos se voltaram para o novo Escritório de Gerenciamento de Projetos (PMO), aprovado por ele alguns meses atrás. Durante sua estada de quase vinte anos na AtekPC, Strider nunca testemunhou os tipos de pressão que a indústria de computadores pessoais (PC) sofria agora. Strider reconheceu que a indústria passava por uma transição e que sua organização de Tecnologia da Informação (TI) se envolveria em projetos de importância central nos próximos dias, já que a AtekPC pretende assumir um papel de liderança em tais mudanças. 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 possuía preocupações sobre o que poderia acontecer caso eles tentassem forçar esta ideia. Ao invés de ajudar, ela poderia se tornar outro item na lista crescente de problemas. Havia muitas questões em sua cabeça:

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 início? E quando o envolvimento GP se torna administração para seus próprios propósitos? Quando se cruza a linha?

Strider pensou que compreendia o que este PMO poderia fazer pela AtekPC, mas a iniciativa ainda estava no início. 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 não entendiam o verdadeiro poder da cultura ali, pensou. Como Strider expressou, o PMO havia se tornado parte da cultura AtekPC, e isso exigia pequenas mudanças por um longo período de tempo. Se o PMO se visse lutando contra a cultura, ele definitivamente falharia. Como diretor de informática, ele estava ciente das muitas iniciativas e

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 disfarçados. Casos HBS são desenvolvidos apenas para discussão em sala. Os casos não têm o objetivo de servir como endosso, fontes ou dados primários, ou ilustrações de gerenciamento eficiente ou ineficiente. Copyright © 2007 reitor e Colegas da Harvard College. Para solicitar cópias ou permissões 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 publicação poderá ser reproduzida, armazenada em um sistema de recuperação, usada em planilhas ou transmitidas de qualquer forma ou por qualquer meio-eletrônico, mecânico, fotocópia, gravação, ou similares sem permissão da Harvard Business School.

http://www.hbsp.havard.edu/



responsabilidades que teria de cobrir com seus recursos limitados, e sabia que o PMO era apenas um deles. Ele não 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 não poder trabalhar mais rápido. Ele também estava tentado pelo pensamento de dar mais recursos para o PMO e cancelar outros projetos. Mas, em sua opinião, isso seria uma iniciativa audaz e de curta duração - muita coisa, muito cedo e muito rápido. Strider fechou sua pasta e se dirigiu para o elevador. Sua equipe sênior de gerenciamento de TI estava com ele há muitos anos. Ele sentia confiança 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 direções estratégicas de negócios com recursos TI, e essa era a essência do PMO. Havia pequena margem para erros na AtekPC nessa época de mudanças.

Formação da Indústria A indústria de informática passava por sérias pressões sobre custos e passava por um período de consolidação. Com as quedas das margens de lucros, os fabricantes de computadores iniciavam estratégias de redução de custo voltadas para a melhora da eficiência de suas cadeias de suprimentos, ao mesmo tempo em que reduziam o custo da distribuição. De acordo com um artigo recente de jornal:

Os últimos resultados financeiros dos fabricantes de computadores mostram uma redução nas vendas e na lucrabilidade. Tanto as empresas quanto os consumidores estão ficando com seus computadores por mais tempo para evitar custos e as complicações relacionadas com a atualização de seus equipamentos. Como consequência, as compras estão sendo adiadas e os fabricantes procuram novos mercados para oportunidades de crescimento. A indústria parece passar por uma onda de consolidação 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 título “Definham os Computadores?” As ameaças relatadas em suas análises eram mundiais e apresentavam uma variedade de fatores, incluindo a popularidade crescente de telefones celulares, PDAs e software de aplicação baseada na internet.

Para a maioria das pessoas, o e-mail é o aplicativo de uso mais importante. Por um grande período de tempo, para enviar e receber e-mails era necessário ter um computador completo. Entretanto, hoje em dia, empresários e consumidores querem colher os benefícios de ser capazes de acessar o e-mail de qualquer lugar, 24 horas por dia, sem a inconveniência de ficar carregando um notebook por todos os lados. Hoje, telefones celulares e PDAs oferecem esta funcionalidade, fazendo com que muitas pessoas questionem a

2 Smith, Davis “PC Makers face increased price competition and industry consolidation”, Metropolitan

News Journal, 17 de fevereiro de 2007, p.B7.



necessidade de transportar um computador. Nos dias da explosão do computador, o mercado era vasto, mas o crescimento desacelerou consideravelmente. Mais além, com a popularidade crescente de aplicações baseadas na internet, tanto empresários quanto consumidores compram cada vez mais máquinas mais baratas que podem acessar e executar aplicações baseadas na internet e não precisam de grande capacidade de processamento local ou de armazenamento. Tendo ignorado a realidade por anos, os fabricantes de computadores finalmente estão fazendo algo. Para cortar custos, eles já estão aprimorando suas operações por meio do uso de tecnologia da informação 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 médio porte nos EUA, tendo em 2006 vendas de $1,9 bilhão. A AtekPC empregava 2.100 funcionários plenos e mais 200 de meio período. Apesar da história de rápido crescimento nos anos 1990, a AtekPC se viu lutando junto de outros fabricantes de computadores pelo mundo enquanto passavam pela transição de uma indústria em crescimento para uma indústria madura. Strider explicou:

A indústria dos computadores mudou e continua a mudar em passo acelerado. Em determinado ponto, a indústria dos computadores se aproveitou de grandes taxas de crescimento e de boas margens de lucro. Como consequência, nós tendemos a não ser tão cuidadosos como deveríamos ter sido em relação ao controle de custos e a como lidar com ameaças competitivas. Agora, claro, a situação mudou e nos deparamos com uma competição crescente de fabricantes asiáticos de computadores que fizeram a transição de fabricação por contrato para a produção sua própria marca. A indústria dos computadores passa por uma consolidação conforme grandes participantes adquirem os menores para obter maior escala. Deste modo, este é o pano de fundo de nossa indústria hoje. Nós possuímos uma necessidade maior do que nunca de sermos agressivos e nos movermos rapidamente, de modo que possamos reduzir custos e obter novos mercados. Nós precisamos nos tornar uma empresa mais ágil de modo que nossas capacidades sejam mais consistentes com o que nosso nome significa. No futuro, nós também teremos de nos especializar mais em relação ao nosso uso de TI ou correremos o risco de nos tornarmos não lucrativos ou um alvo para uma incorporação agressiva.

No outono de 2006, a AtekPC já havia iniciado diversas iniciativas e projetado o posicionamento da organização para o futuro. Uma dessas iniciativas foi a criação do Escritório de Planejamento Estratégico, cuja responsabilidade era propor mudanças de negócios. Sob a orientação do Escritório de Planejamento Estratégico, o esforço 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

3 “Whither the PC?”, Global News, 20 de março de 2007, p;9



e efetivo para que as propostas do Escritório de Planejamento tivessem sucesso. Em março de 2007, o Escritório de Planejamento Estratégico e o PMO inicial estavam em operação há apenas alguns meses. De acordo com Strider, a AtekPC passava por uma competição crescente sobre o preço e a administração sofria grande pressão para garantir que cada ação tivesse um retorno visível.

Tecnologia da informação na AtekPC Com o passar dos anos, a AtekPC desenvolveu um amplo portfólio de aplicações. Estas aplicações eram focadas principalmente no nível operacional para funções comerciais típicas de um fabricante de computadores, como contabilidade, fornecimento, produção, vendas e distribuição. A integração de arquitetura destes sistemas de aplicação era obtida apenas moderadamente, de modo que em 2007, as áreas funcionais recebiam frequentemente serviços discretos de informação com pequena integração entre funções. Projetos de sistemas de informação eram normalmente esforços operacionais ou de manutenção feitos sob solicitação de determinada área funcional. Eles costumavam ser projetos pequenos e de médio porte em relação ao tamanho e a duração, e eram administrados informalmente sem práticas padronizadas. Como o Diretor de Desenvolvimento de Aplicação, Richard Steinberg explicou:

Historicamente, nós sempre cuidamos de nossos próprios assuntos. Nós tivemos diversos projetos operacionais e várias melhorias acontecendo, mas tivemos poucas aplicações de negócios... Com o passar dos anos, certas pessoas na empresa reconheceram que a qualidade do trabalho feito nos projetos poderia ser melhorada. Conforme começamos a observar o que era necessário fazer no futuro, percebemos que tínhamos mesmo que aperfeiçoar 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. Então, iniciei um plano para um PMO, basicamente uma metodologia de gerenciamento de projetos para todas as minhas áreas.

O ambiente de mudança 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 padronização 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 práticas formais, estes projetos não resultaram na formalização duradoura das práticas. Steinberg explicou:

Se voltar alguns anos, para Y2K, para a conversão de nosso sistema de gerenciamento de ordem; nos maiores projetos, eles usaram uma abordagem de gerenciamento de projetos. Eles não perceberam. Eles reuniram todos, conversaram sobre o era necessário ser feito, e o fizeram. Todos distribuíram elogios e disseram “foi bem feito. Agora que terminamos, devemos voltar a fazer projetos normalmente.” Eles não perceberam esse era o modo de se trabalhar. De repente todas as preocupações 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 alguém da equipe de desenvolvimento que era responsável por determinada área funcional. Por exemplo, o analista Chefe responsável pela Produção também teria a função de gerente de projetos. O analista Chefe supervisionava grupos de trabalhos de analistas e programadores de vários níveis diferentes de habilidade e eram responsáveis por satisfazer as solicitações das áreas funcionais e pelo desempenho de seus grupos de trabalho. Usando um processo informal de iniciação de projeto, os usuários solicitavam serviços 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 Produção, resolvia quaisquer problemas e conflitos, se necessário; de outra maneira, a solicitação era recebida, executada e entregue por meio do Analista chefe. Métodos de Projeto, documentação, práticas e ferramentas eram individualizados pelo analista Chefe com pouca ou nenhuma consistência pelos grupos de TI ou áreas comerciais. A AtekPC percebeu os muitos benefícios 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 consequência de sua abordagem informal, eles forneceram uma resposta rápida para solicitações de usuários e foram capazes de equilibrar necessidades críticas emergentes em seus grupos de trabalho com alguns conflitos. Por causa deste histórico de entrega responsiva, foi depositada confiança considerável entre a área funcional e seu Analista Chefe. O relacionamento baseado em confiança foi altamente personalizado para os funcionários como indivíduos, 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 Produção, descreveu seu trabalho nesta função:

Em meu mundo, tenho uma variedade de usuários com quem converso. Eles costumam dizer: “Preciso disso”. Alguns diriam: “Preciso muito disso. Posso pegar? É uma emergência e preciso disso”. Eu me virava, olhava para o que as pessoas estavam trabalhando e dizia: “Eu preciso que você troque a peça. Dê-me duas horas, dois dias ou o quanto for necessário. Nós precisamos fazer essa pequena peça”... Eu faço um cronograma baseado no que todos em meu grupo estão fazendo e o que eu sei após falar com ele.

Esta abordagem informal ao gerenciamento de projetos costumava ser a norma na AtekPC. Historicamente, a visão prevalecente era a de que a TI era periférica às atividades comerciais principais da AtekPC. Como consequência, a TI era vista como uma recebedora de ordens, esperada a prestar serviços sob demanda. Durante a última década, os projetos se tornaram cada vez mais focados em operações e manutenção em um grande esforço para melhorar a eficiência nas funções comerciais. O desenvolvimento de sistemas de integração entre funções e o uso de tecnologias de internet eram apenas duas necessidades emergentes conforme a AtekPC lutava com mudanças radicais



em sua indústria e mercado. Os novos projetos exigidos eram maiores, mais complexos e envolviam diversas áreas funcionais e tecnológicas, 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 métodos correntes informais de gerenciamento de projetos. O PMO da AtekPC estava sendo implementado para oferecer mais consistência e melhores práticas para projetos comerciais e de IT. Entretanto, implementar um PMO na AtekPC por si só era um desafio que necessitava de um gerenciamento habilidoso para ter sucesso. Um difícil equilíbrio deve ser mantido entre a manutenção e o novo desenvolvimento, assim como entre os recursos que iam para atividades de desenvolvimento contra os recursos que iam para atividades de administração de projetos sob o novo PMO. Strider descreveu o desafio:

Nós ainda não entendemos tudo. É melhor do que achar que sabe quando, na verdade, não sabe. No departamento de TI, nós temos de ser mais capazes de administrar conflitos entre novas iniciativas comerciais críticas e operações com mudanças incrementais aos sistemas existentes. Nós não podemos sacrificar um pelo outro. A história é que fazíamos apenas manutenção operacional e agora temos a cultura de fazer ambas.

Missão do PMO A missão do PMO da AtekPC foi evoluindo gradualmente desde sua criação no final de 2006. Desde a primavera de 2007, não houve um consenso sobre seu objetivo, suas responsabilidades e sua autoridade. Enquanto a documentação formal e os planos para o PMO não existiam, o objetivo imediato era estabelecer o escritório e provar seu valor. O consenso geral era de que o PMO era para executar os benefícios derivados de práticas consistentes de projetos. Apesar de não especificar de modo claro ou mensurável neste momento, esses benefícios eram expressos em uma variedade de termos, variando de melhorias de TI em desempenho de projeto, eficiência e utilização 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 indústria do computador e em seus desafios, penso em duas coisas que podem estar se dirigindo a um PMO. Uma pode ser a redução de custos. Não podemos nos dar o luxo de sermos descuidados. Sinceramente, devemos ser muito mais cuidadosos no modo em que usamos nossos recursos. Outra motivação para melhorar os projetos seria nos tornarmos mais criativos, adaptativos, ágeis no lançamento de novos produtos. E para lançar novos produtos, o que você diria que está guiando estas iniciativas além do gerenciamento de projetos?

Entretanto, as responsabilidades do PMO não eram tão claras. No momento as responsabilidades do PMO eram limitadas a projetos de TI, apesar de haver uma discussão sobre expandir seu escopo para um PMO de nível empresarial que, no futuro, incluiria projetos comerciais. Os deveres específicos 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 serviços que permitiam o sucesso de projetos individuais. Por outro lado, responsabilidades comerciais voltadas a serviços que podiam melhorar todos os projetos como gerenciamento de portfólio, padrões de GP, métodos e ferramentas e arquivos de desempenho de projeto. O esclarecimento das responsabilidades do PMO evoluía continuamente conforme a AtekPC tentava obter apoio para chegar a um acordo em sua missão e constituição: Na AtekPC, responsabilidades focadas no projeto eram meios iniciais usados para provar méritos de seus PMO. O plano era criar aceitação ao consultar e fazer tutoria para projetos individuais. Mark Nelson, o novo Gerente PMO, falou sobre este esforço:

O que fazemos desde outubro de 2006 tem sido fornecer tutoria e apoio para a administração 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 – reuniões regulares com as equipes, relatório de situação, questões de manutenção e riscos de gerenciamento.

No final, o PMO continuou a receber apoio das áreas funcionais e de funcionários de TI relacionados com estes projetos. Uma das maiores limitações era a escassez de recursos experientes em PMO disponíveis para apoiar tais projetos. Complementando Nelson, havia outros três gerentes de projeto atribuídos para o PMO e eles eram funcionários contratados. Usar a equipe PMO para gerenciar diretamente os projetos era feito com pouca frequência, entretanto, Nelson tinha designado um de seus gerentes de projeto para projetos críticos relacionados ao lançamento 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 padrões de projetos. Steven Gardner, Gerentes de Produção de Sistemas, comentou sobre um processo de criação de um projeto que o PMO introduziu:

Nelson nos ajudou a desenvolver o que chamamos de “formulário de ideia”, onde nós tentamos eliminar diversas chamadas aleatórias que chegam para nós. Nós tentamos priorizar melhor no que trabalhamos, e usar este “formulário de ideia” nos direciona na construção de uma compreensão de negócios de onde a ideia surgir. Isso nos força 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 braços em torno do que estamos trabalhando.

Os serviços focados na empresa desenvolvidos pela equipe PMO de Nelson estavam sendo bem recebidos. Enquanto o avanço nesta área estava sendo restrito pelos recursos limitados do PMO, houve um consenso claro,



mesmo no nível do Diretor de Informática, de que o PMO era responsável por estabelecer, publicar e disseminar práticas de projetos, padrões e ferramentas. Por outro lado, o gerenciamento de portfólio (a mudança de gerenciar projetos para estabelecer técnicas para correntes contínuas de gerenciamento de projetos) e o arquivamento de responsabilidades (o estabelecimento de registros de arquivos de projetos para compartilhamento de conhecimento) não estavam sendo abordadas. Nelson esperava ser capaz de incluir tais deveres na missão conforme o PMO se desenvolvia, mas sem recursos adicionais, não era possível no curto prazo. Ele também percebeu que recursos adicionais só seriam possíveis sendo retirados de outras responsabilidades críticas, e isso poderia comprometer a capacidade de manter efetividade operacional. Era um equilíbrio desafiador. A última área de interesse em relação à missão do PMO era a questão da autoridade. Strider reconhecia que a aplicação destas novas práticas de projeto exigia uma autoridade formal, e ele estava preparado para fornecê-la apenas quando o PMO tivesse se provado em negócios e TI. Nos esforços iniciais de desenvolvimento, Nelson trabalhava sob o benefício de uma autoridade implícita que vinha de um reconhecimento geral das mudanças de direção da administração. Entretanto, o PMO também teve o apoio do vice-presidente sênior. Larry Field, diretor do Grupo de Apoio de Gerenciamento de Projetos, era um membro principal da iniciativa PMO desde o seu início e explicou: “para nós sermos eficientes, devemos ter apoio vindo de cima. E tivemos tal apoio do vice-presidente sênior, 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 valorização dos serviços PMO. Mesmo estes eram limitados a tais áreas funcionais e às áreas de TI envolvidas no PMO. Atualmente não há planos para ampliar o uso em nível empresarial. Nelson resumiu esta abordagem com as seguintes observações:

O mais importante é a tutoria que está ocorrendo e realmente gerenciando os projetos. Nós estamos sendo pacientes de modo que podemos obter alguns bons exemplos concretos que podemos mostrar a eles. Nós 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 três ou quatro meses porque acertamos estas práticas” E isso é essencial porque nos permite mostrar nosso valor. Essa deve ser a abordagem por enquanto.

Organização PMO Dois modelos organizacionais foram levados em consideração 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 aquisição de especialistas em gerenciamento de



projeto, sejam fontes internas ou externas, e os usavam para gerenciar projetos sob a direção do PMO. Na versão extrema do PMO-pesado, nenhum projeto seria operado fora do gerenciamento e do controle direto do PMO. Este modelo se concentrava no desenvolvimento de técnicas de gerentes de projetos internos que não eram formalmente relacionados com o PMO. Na versão 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 responsável pela execução do projeto. A questão onde o PMO deveria se localizar no espectro do PMO-pesado para o leve gerava várias discussões e pouco s acordos. Strider falou sobre esta controvérsia:

Neste momento, são quatro pessoas em tempo integral... Dada a velocidade em que nós, como empresa, desejamos nos mover – nós, 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 aplicação é muito ampla. Não vejo todo o gerenciamento sendo entregue para este grupo. Há uma diferença de opinião entre mim e o PMO sobre o assunto neste momento. Nós teremos que descobrir um meio termo... Estou convencido que deve ser leve. Isso não significa que eu não o questiono, por que há muitas pessoas neste departamento que me contestam frequentemente sobre o assunto. O que está tudo bem, quero dizer, não preciso que fiquem concordando comigo o tempo todo.

Enquanto Nelson concordava em trabalhar com uma equipe pequena no início, ele sentia que os atrasos desta abordagem podiam comprometer a capacidade de fornecer serviços PMO e de demonstrar seu valor para as éreas funcionais do negócio. Entretanto, ele e outros gerentes reconheceram que os recursos não eram gratuitos, e que eles vinham de algum lugar, o que significava reduzir as capacidades do trabalho de outras pessoas para avançar seu próprio. 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 limitações, ele esperava obter mais ajuda, conforme ele explicou:

Caso não houvesse restrições, 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 começar. Mas com o passar do tempo, seria possível chamar gente da própria empresa. Eles fariam parte do PMO. Deste modo teríamos vários graus de experiência variando de GP seniores a juniores. Conseguiríamos muito apenas com esta etapa.

Steinberg estava preocupado com os recursos necessários e em como as áreas funcionais poderiam responder ao se adicionar mais pessoas neste momento. Ele explicou: “Qual a implicação de um patrocinador em Vendas tentando iniciar um projeto que tem aprovação do PMO? Eles não entendem literalmente o que é o PMO. Eles acham que é um bloqueio e um obstáculo ao avanço – algo burocrático.”



A preocupação 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 também tinha que garantir que a TI mantivesse se equilíbrio e fizesse o trabalho. Como Strider explicou:

Agora, se você adicionar pessoas, onde você as inclui? O fato de você poder adicioná-las é um avanço. Você as adiciona neste PMO, ou você as adiciona em outro lugar? ... A questão é como você faz para ir aonde precisa, mas sem violar a cultura de modo a gerar uma grande confusão... Porque o PMO não pode fazer os projetos. Eles não vão escrever o código, eles não vão instalar os servidores; eles não vão se encontrar com os usuários que entendem os requisitos funcionais; eles não vão se encontrar com os clientes.

Na linha de frente, Star estava obtendo algumas informações 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 mudanças. Ela certamente estava esperando por mais ajuda, ela tinha de lidar com vários problemas de administração 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 não tinha certeza do que estava realmente acontecendo. Ela descreveu sua compreensão 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 nós seríamos sua equipe. Eu estava pensando que eu ainda seria a pessoa responsável – o líder - por tal projeto, pelo grupo com quem estava trabalhando. Mas seria, essencialmente, responder para este gerente de projeto que possuía as habilidades e o conhecimento e o treinamento e todas as ferramentas para nos ajudar a avançar. Isso ocorria porque histórico em gerenciamentos de projeto é um processo e ferramentas que eu mesma criei para criar, analisar e manter registros. Então pensei que eles viriam com estas ferramentas e, em breve, estariam nos ensinando; e em breve nos tornaríamos gerentes de projetos por conta própria.

Gerente de Star, Gardner tinha a expectativa de que o modelo PMO seria mais pesado do que leve. Ele já estava convencido dos méritos do PMO do uso da “forma de ideia” de seu grupo para obter solicitações de novos projetos. Em sua compreensão, o PMO forneceria uma rede de recursos de gerente de projeto. Ele falou sobre sua visão do modelo organizacional:

Eles estão 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 compreensão deles de terem gerentes de projetos nos quais você atribui os vários projetos por departamento. Por exemplo, nós estamos usando um agora para este novo lançamento de projeto em adição aos projetos que temos agora. Ela vai começar a assumir a função de planejamento de linha de tempo, cronograma, convocar as pessoas certas e garantir que todos estejam informados – as típicas funções de gerentes de projeto... Em relação ao gerenciamento de projetos, o projeto é de sua responsabilidade. É seu trabalho.



Na visão de Gardner, ele manteria o controle do projeto, e em sua duração, o gerente de projeto da equipe do PMO seguiria suas instruções. Os recursos seriam atribuídos em uma estrutura de matriz pela duração do projeto. Era isso que Gardner fazia com o gerente de projeto PMO atual que foi atribuído para um de seus projetos, e na opinião 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 não era apenas sobre a equipe de TI,

O problema com um PMO-pesado não é apenas levar os gerentes de projetos e analistas. Também são os recursos empresariais. Hoje, nós temos gerentes de linha que trabalham em diversos projetos além de suas funções comuns, e eles não podem acumular ainda mais. O que realmente dirige vários projetos qualquer empresa é a disponibilidade dos recursos de trabalharem em tais projetos. Ter os recursos empresariais disponíveis já está se tornando um problema para nós. Com um PMO-leve, nós estamos melhores alinhados com o lado empresarial em relação aos números de recursos, e é um equilíbrio melhor.

Nelson destacou o PMO-pesado como o melhor modelo para a AtekPC, mas ele reconheceu que não seria capaz de obter a aceitação 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 aprovação, ele queria implementar uma abordagem PMO-pesado, fornecendo gerentes de projetos para vários grupos. Conforme disse:

Não 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 mudança geral por qual a empresa passava, eles não estava prontos para tomar este tipo de decisão... com estes processos e procedimentos que estamos desenvolvendo, nós vamos estabelecer planejamento de projeto, acompanhamento, iniciação e encerramento. Todos os gerentes de projeto ajudarão a organizar o TI.

Conforme a AtekPC lutava para encontrar o modelo organizacional correto, a equipe PMO trabalhava para fornecer os serviços 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 tensão constante que deveria ser trabalhada cedo ou tarde. Com mais recursos, Nelson acreditava que sua equipe poderia fornecer mais apoio mais rápido e se mover mais rapidamente em projetos críticos e padrão. Por outro lado, Strider lembro Nelson que o PMO era uma das responsabilidades na organização de TI da AtekPC. Haviam outras necessidades de recursos em suas próprias justificativas e devoluções. Portanto, a questão do PMO-pesado contra o PMO-leve não era uma decisão simples ou fácil.



Implementação e cultura A AtekPC estava envolvida em um desafio difícil de tentar implementar métodos padrão em uma empresa que não estava acostumada a processos e padronização consistentes e disciplinados. O gerenciamento de TI percebeu que no futuro eles dependeriam de padrões e processos consistentes para administrar seus projetos e levá-los adiante. Independentemente, implementar um PMO em um ambiente não-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:

Nós estamos mudando de uma empresa que não possuía uma administração de projetos formais para uma empresa que gostaria de ser bastante formal. Nós seremos algo no meio. Nós não podemos ser rígidos sobre o gerenciamento de projetos. Esta cultura não nos permitirá a fazer isso. Você deve misturar a cultura com os métodos e os processo e agora eu até mesmo ouço onde o processo não pode ser tão rígido. Se ficarmos muito rígidos, ele falhará. Nós temos de ser um pouco fluídos e dinâmicos em determinados momentos, e isso incomoda algumas pessoas do PMO, mas temos que fazer desse modo aqui. Para obter sucesso, nós devemos desenvolver uma organização que será flexível e precisa neste relatório. Esta é a minha luta – fazer com que o gerenciamento de projetos caiba em uma cultura que está mudando, mas que ainda não atingiu o nível.

Às vezes, para aqueles envolvidos, as forças de oposição ao PMO parecem esmagadoras. Strider imaginava o quanto aberta à própria organização de TI estava em relação à mudança de seus processos e de se adaptar para novas práticas de gerenciamento de projetos. Essa era uma questão cultural central em sua cabeça. Muitas pessoas da equipe, incluindo gerentes, tinham pouca ou nenhuma experiência com práticas formais de gerenciamento de projeto. Muitos poucos sabiam como usar qualquer ferramenta de software disponível, como o Microsoft Project. Além dessas barreiras sobre o conhecimento, a informalidade das práticas 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 também achava a informalidade atraente, já que os custos e o desempenho dos projetos não eram registrados. As áreas funcionais não eram responsáveis por medir os benefícios resultantes de seus projetos, e a equipe de projetos de TI não trabalhava com um orçamento de projeto pré-definido. Outra fonte de resistência era a falta de compreensão nos níveis de valores de gerenciamento de projetos formais. Juntos, estas fontes de resistência a um PMO criaram barreiras culturais formidáveis 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 discussão recente em volta de sua mesa, ele resumiu a situação: “minha opinião é que tenho duas opções. 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 inteligência. Mas se você sempre se opuser a cultura, você perderá.” No momento, a implementação estratégia do PMO na AtekPC era trabalhar com a cultura e desenvolver forças que divulgariam o PMO e superariam a resistência cultural. Forças promocionais incluíam tutoria, aconselhamento e treinamento que estavam sendo fornecidos pela equipe PMO. A empresa estava claramente sob pressão para mudar o modo como fazia negócios, mas não havia consenso entre os gerentes seniores em relação o nível de integralidade do PMO para alterar o processo. Na opinião 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 necessário mais comprometimento das áreas funcionais. Uma das principais questões culturais em sua cabeça era com que velocidade as áreas funcionais (ou seja, os clientes de TI) estaria a se adaptar a um processo mais formal. Eles deveriam estar dispostos a priorizar projetos e a fazer escolhas difíceis e cessões. Em alguns casos, para avançar 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 estratégia de implementação era um trabalho lento e exigia muita paciência. Para ele, a luta era sobre criar e fornecer um sucesso comprovado. Ele expressou o desafio conforme o via:

Não posso chamar de cima para baixo (sua abordagem de implementação) porque obtemos a aprovação de cima para que nós começássemos. Mas é como se fosse quase de cima, mas não exatamente lá. É visto como burocrático, ou como tendo potencial para ser burocrático. E isso ocorre por conta da própria indústria e de seu passo- retire os produtos - pegue as ordens. Uma das coisas que ouvimos vindo de cima é “Não deixe este gerenciamento de projetos e de processo atrasar tudo. Eles são ótimos, e queremos vê-los funcionando; mas não deixe que eles atrapalhem”.

Como diretor de Desenvolvimento de Aplicações, Steinberg foi um dos primeiros apoiadores do PMO e ele viu algum avanço ao se quebrar tais barreiras culturais. Quando Steinberg chegou pela primeira vez na AtekPC, ele recebeu a tarefa de implementar uma metodologia padrão de desenvolvimento de software. O esforço inicial para tal metodologia falhou, em sua opinião, porque a cultura não era correta para uma abordagem disciplinada. Agora, ele apoiava completamente este esforço de PMO, e ele trouxe uma compreensão profunda sobre a cultura AtekPC e sobre seus desafios. Sob este ponto de vista, apenas trabalhar com grupos de negócios 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 tentássemos fazer com que tivesse visibilidade fora deste departamento, não fui capaz de obter nenhuma visibilidade oficial. O que houve foi que tentamos envolver nosso GP em projetos e os enviamos para os usuários relacionados.



Produção foi uma das primeiras áreas. O representante do projeto TI em Produção perguntou “o que este PMO vai fazer?” Quando contamos para ela, ela se juntou a iniciativa. O mesmo aconteceu em Vendas. Ele não foi bem recebido em certos grupos, mas, felizmente, foi em certas áreas... Produção já aceitou, Vendas está começando a aceitar. Mas não tenho certeza se as outras áreas já estão aceitando este conceito.

Com algumas áreas dando apoio, a equipe PMO continuou seus esforços de implementação. Como Nelson comentou, seus avanços na época tinha sido “passos de bebês”. A frustração com o progresso lento os tentava a usar outra abordagem – forçar a mudança 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 padrões e métodos rapidamente, e eles defendiam uma estratégia de implementação mais rápida 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 mais consistente. A administração de TI estava que tal abordagem falharia porque não podiam forçar uma mudança radical na AtekPC. Portanto os gerentes seniores de TI encorajavam uma estratégia lenta e de incremento que permitiria que o conceito de PMO se provasse com pequenas vitórias obtidas tutorando um projeto de cada vez.

Governança A questão da governança do PMO não havia sido amplamente discutida, mas já possuía certa importância. No momento, não havia guias ou linhas de tempo para sua maturação, então, não havia modo de medir o desempenho PMO além do uso de opiniões 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 organização de projeto mede seu sucesso? Umas das preocupações era se os gerenciamento de projetos, devido à burocracia, iria atrasar os negócios. Ainda há preocupações sobre isso. Nós estamos tentando dizer que iremos acelerar as coisas e fazer tudo mais rápido com menos retrabalho. Então, como nos avaliamos para dizer que estamos tendo sucesso? Nós realmente ainda não descobrimos tal métrica.

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á difícil por que não havia muito registro de dados antes. Mas mesmo que não seja muito preciso, podemos mostrar que... devemos ser capazes de mostrar avanço.” Dada esta abordagem para avaliação do desempenho PMO por meio de consenso subjetivo e dados sem comprovação, a próxima questão da governança era descobrir para quem o PMO responderia. No momento, ele



respondia para Steinberg como Diretor de Desenvolvimento de Aplicações, o que, em sua opinião, era devido à sua experiência com metodologias e padrões. Ele explicou algumas opções atuais de governança:

Atualmente ele responde para mim no desenvolvimento de aplicação, 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 não para o Diretor de informática, para outro local na empresa... Acredito que haja uma possibilidade de responder para o vice-presidente sênior, ou se criarmos este novo Escritório de Planejamento, talvez para ele.

Strider reconheceu que o modelo atual de governança era apenas temporário, e explicou seus pontos de vista:

O único motivo para estabelecermos um PMO é porque existe um Escritório de Planejamento para a empresa, e o vice-presidente sênior está comprometido com uma abordagem de gerenciamento de projetos mais planejada e rigorosa. Não poderia lidar com isso internamente na TI a menos que tivesse apoio... Nesse momento, ele responde para o chefe e Desenvolvimento de Aplicação. Steinberg e eu conversamos que, com o tempo, provavelmente, o PMO responderá diretamente para mim. Mas, sinceramente, agora não tenho tempo... Também há o escritório de Planejamento que não responde para mim, mas para o vice-presidente sênior, e essa é uma possibilidade.

Entendendo esta interação próxima entre o novo Escritório de Planejamento e o PMO, Steinberg compartilhou sua preocupação sobre ele permanecer na TI.

Acredito que enquanto permaneça um elemento, uma divisão separada na TI, sempre haverá esta relação “nós-eles”, e o sentimento de que estamos lá para fazer do nosso jeito, é nosso próprio trabalho e nossa função o fazerele funcionar melhor... Nós fizemos alguns trabalhos com aplicações de grupo e tivemos sucesso. As pessoas querem mais. Então espero que eles tenham bastante espaço para iniciar o PMO e para mostrar os benefícios. Isso venderá para as outras áreas e permitirá que continue.

Decidindo o melhor modo de se avançar A indústria da computação está mudando, e a AtekPC estava dedicada a lidar com pressões dramáticas de competidores maiores, como HP, Dell e Lenovo. Para competir com uma indústria em transformação na qual ocorria consolidação, a AtekPC implementou um Escritório de Planejamento corporativo. Reconhecendo a função que a TI teria de cumprir para permitir que a AtekPC reagisse às pressões da indústria, o vice-presidente sênior apoiou a criação do PMO na TI. A função 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 tão 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 necessário para produzir e enviar os produtos. A criação do PMO já revelou diversas questões, algumas que se provaram muito controversas para se resolver imediatamente. A AtekPC se sentia seu caminho em direção ao PMO. Conforme tentavam criar um acordo sobre questões básicas do PMO, todos na organização de TI estavam cientes dos desafios que enfrentavam e o risco relacionado ao fracasso. Os projetos se acumulavam rapidamente. O sucesso dependeria inteiramente da decisão e de seus esforços, e esse era um motivo de preocupação para eles. O tráfego estava parado enquanto Strider dirigia pela interestadual, tentando sair de Metropolis e voltar para sua família em casa naquela noite. Isso deu tempo para que ele pensasse sobre o PMO. Ele havia guiado sua equipe de gerenciamento para esta estratégia de implementação. Ele tinha opiniões fortes de que o modelo PMO-leve era o mais adequado. Ele evitava contratar novos funcionários plenos para o PMO. Ele estava preocupado com quantas questões a implementação 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 não 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”.



Dir

eto

r d

e In

form

átic

a

Jon

Str

ider

Dir

eto

r d

e te

cno

logi

as e

op

eraç

ão

Dir

eto

r d

e d

esen

volv

imen

to d

e ap

licaç

ão

Ric

har

d S

tein

ber

g

Ger

ente

de

pro

jeto

s d

e su

bst

itu

ição

de

sist

emas

ava

nça

do

s

Ger

ente

do

gru

po

de

trab

alh

o d

e

com

un

icaç

ões

Dir

eto

r d

o G

rup

o d

e ap

oio

de

gere

nci

amen

to

de

pro

jeto

s

Larr

y Fi

eld

Ger

ente

de

sist

emas

fin

ance

iro

s

Ger

ente

de

sist

emas

de

ven

das

Ger

ente

de

sist

emas

de

pro

du

ção

Ste

ven

Gar

dn

er

An

alis

ta c

hef

e Li

nd

a St

arr

An

alis

ta C

hef

e

An

alis

ta C

hef

e A

nal

ista

Ch

efe

An

alis

ta C

hef

e

Dir

eto

r P

MO

Mar

k N

els

on

Ger

ente

de

pro

jeto

Ger

ente

de

Pro

jeto

An

exo

1: D

iagr

ama

org

aniz

acio

nal

da

Tecn

olo

gia

da

info

rmaç

ão d

a A

tekP

C



Anexo 2: “Formulário Ideia” AtekPC

FORMUÁRIO DE DESENVOLVIMENTO IDEIA

Seção A. (Solicitante preenche esta seção) Nome do Projeto Nome do solicitante: Data de envio da solicitação: Nome do sistema (se conhecido): Necessário até:

Seção B (revisor preenche esta seção) Revisor Ideia: Data de revisão: Id do projeto

[ ] Aprovado [ ] Reprovado – motivo para não aprovação

Seção C. Tipo de trabalho (revisor preenche esta seção) [ ] Melhoria [ ] Emergência [ ] Conserto

Seção D. (Solicitante preenche esta seção) 1. Forneça uma descrição (o que é?):

2. Porque devemos fazer? (Explique o valor comercial e selecione o tipo de benefício adequado) Explicação: Tipos de benefícios (mais de um tipo pode ser utilizado) Estime se possível [ ] Cria receita Receita anual estimada: __________ [ ] Evita custos Custos evitados estimados: __________ [ ] Economia de custos Custos anuais economizados: __________ [ ] Confiança operacional [ ] Melhoria de atendimento ao cliente [ ] Melhoria na qualidade

3. Escopo: (Descreva o que é incluído e excluído)

4. Resultados: (Mudanças de relatórios, tela nova, entrada de dados, etc...)

5. Departamentos / clientes afetados:

6. Deduções

7. Projetos relacionados

8. Risco/impacto de não executar o projeto

Fonte: AtekPC

Documents

Estudo de Caso 1