Gerenciamento Projetos

MBA EXECUTIVO
GERENCIAMENTO DE PROJETOS
Emanuel Edwan de Lima, M. Sc. Vicente Fernandes Tino, M. Sc.
Aluno(a): ______________________________________________________________ Curso:____________________________________Turma: ______________________
Sumrio
1 1.1 1.2 1.3 1.4 1.5 1.6 1.7 2 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 3 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 PROGRAMA DA DISCIPLINA ...................................................................................................... 1 EMENTA ................................................................................................................................... 1 CARGA HORRIA TOTAL ............................................................................................................... 1 OBJETIVOS ................................................................................................................................ 1 CONTEDO PROGRAMTICO ......................................................................................................... 1 M ETODOLOGIA .......................................................................................................................... 2 CRITRIOS DE AVALIAO............................................................................................................. 2 BIBLIOGRAFIA RECOMENDADA ...................................................................................................... 3 TEXTO PARA ESTUDO ................................................................................................................ 4 INTRODUO ............................................................................................................................ 4 O GERENTE DE PROJETOS ............................................................................................................. 5 O CICLO DE VIDA DOS PROJETOS .................................................................................................... 6 PROCESSOS DE GERENCIAMENTO DE PROJETOS.................................................................................. 8 REAS DE CONHECIMENTO DO GERENCIAMENTO DE PROJETOS ........................................................... 18 ESTRUTURA ORGANIZACIONAL PARA PROJETOS ............................................................................... 24 ESCRITRIO DE PROJETOS........................................................................................................... 28 ATIVIDADES DURANTE O CICLO DE VIDA DO PROJETO ........................................................................ 29 CONCLUSES ........................................................................................................................... 49 MATERIAL COMPLEMENTAR................................................................................................... 50 ESTUDO DE CASO - MPAR ........................................................................................................ 50 ESTUDO DE CASO: FOX M EYER .................................................................................................... 54 ESTUDO DE CASO - GLOBALSTAR: CONECTANDO TODO MUNDO, DE TODO LUGAR ................................... 58 OURO PERDIDO ....................................................................................................................... 61 O EXEMPLO DA BOMBA ATMICA ........................................................................................... 69 VOC = SEUS PROJETOS ............................................................................................................. 71 COMO ACELERAR O DESENVOLVIMENTO DE NOVOS PRODUTOS ........................................................... 81 GERENCIAMENTO DE RISCOS EM PROJETO: M ELHORES PRTICAS E DESENVOLVIMENTOS FUTUROS ............. 84 GERENTES DE M ULTIPROJETOS, QUAIS COMPETNCIAS SO NECESSRIAS? ........................................... 89
1 Programa da disciplina
1.1 Ementa
Importncia do gerenciamento de projetos. Evoluo da gesto de projetos. Conceituao de projetos. Definio do papel do gerente de projetos. Processos do gerenciamento de projetos. reas de conhecimento do gerenciamento de projetos. Estrutura organizacional para projetos. Ciclo de vida de projetos. Importncia e tipos de escritrio de projeto
1.2 Carga horria total

24 horas/aula
1.3 Objetivos
Uniformizar o arcabouo conceitual bsico de gesto de projetos. Identificar os diversos aspectos envolvidos no gerenciamento de projetos; Introduzir os diversos aspectos que devem ser levado em conta no gerenciamento de projetos; Levar reflexo quanto s estratgias necessrias para a conduo de projetos de sucesso. Determinar as melhores tcnicas e mtodos para planejamento, execuo e controle de projetos. Possibilitar a aplicao prtica do contedo abordado na disciplina.
1.4 Contedo programtico

Vale a pena lembrar que o contedo programtico o detalhamento da ementa. Veja o exemplo a seguir. Compare-o com o exemplo de ementa que lhe foi oferecido.
Importncia gerenciamento projetos
do Introduo ao gerenciamento de projetos de Caracterizao de projetos de sucesso As restries do projeto
Evoluo da gesto de Histrico do gerenciamento de projetos projetos O ambiente de projetos e suas caractersticas Conceituao projetos de O que um projeto? Diferena entre projeto e operaes Gerenciamento de projetos
2 Programas e projetos. Definio do papel do Caracterstica do gerente de projeto gerente de projetos Perfil do gerente de projetos O gerente de projetos na organizao Processos gerenciamento projetos do Processos de iniciao de Processos de planejamento Processos de execuo e controle Processos de finalizao reas de conhecimento Conceitos do gerenciamento de Definies projetos Caractersticas das reas de conhecimento Estrutura organizacional projetos A cultura organizacional para projetos para Tipos de estruturas organizacionais Caractersticas das estruturas organizacionais O papel do gerente de projetos nas estruturas organizacionais Ciclo de projetos vida de Ciclo de vida do projeto e ciclo de vida do produto Atividades durante o ciclo de vida do projeto
Importncia e tipos de Definio de escritrio de projetos escritrio de projeto Tipos de escritrios de projetos
1.5 Metodologia
As aulas buscaro o equilbrio entre a conceituao terica e a aplicao prtica, por meio de aulas expositivas e participativas, buscando a compartilhamento de informaes. Sero realizados estudos de casos e exerccios para demonstrao da aplicao dos conceitos. S ero realizados trabalhos individuais e em grupo, tanto em sala de aula quanto para confeco fora da sala de aula.
1.6 Critrios de avaliao

A avaliao se dar por meio de: - Participao nos exerccios e atividades em sala de aula; Gerenciamento de projetos
3 - Participao nos exerccios propostos para casa, que sero apresentados em forma de seminrio com a escolha do expositor critrio do professor; - Prova escrita individual, dos contedos da disciplina, realizada no final do mdulo.
1.7 Bibliografia recomendada

VERZU, Eric. Gesto de Projetos. MBA Compacto. Campus, 2000. Um Guia do Corpo de Conhecimentos em Gerenciamento de Projetos. Guia PMbok . PMI, 2004. KERZNERm Harold. Project Management, a S ystem Approach do Planning, S cheduling and Controlling. Van Nostrand Reinhold, 1998. VARGAS, Ricardo Viana. Gerenciamento de Projetos. Brasport, 2006. VALERIANO, Dalton. Gerencia em Projetos: Pesquisa, Desenvolvimento e Engenharia. Makron Books, 1998. HEERKENS, Gary R. Project Management. McGraw-Hill, 2002. NEWELL, Michael W. Preparing for the Project Management Professional (PMP Certification ) Exam. Amacon, 2002.
1.8 Curriculum resumido do professor

Emanuel Edwan de Lima Mestre em Gesto Empresarial pela Fundao Getlio Vargas EBAPE RJ, com curso de especializao em gerenciamento de manufatura pela AOTS (The Association for Technical Scholarship) Japo e Engenheiro Eletrnico pelo Instituto de Tecnologia da Amaznia UTAM. Tem mais de 18 anos de experincia em manufatura de produtos eletrnicos, atuando nas reas de Engenharia, Produo, Materiais e Gesto da Qualidade, Gerenciamento de projetos, Transferncia de Tecnologia e Introduo de novos produtos. Examinador do Prmio Nacional da Qualidade 2003, 2004 e 2005, Avaliador do Prmio Ibero-Americano de Qualidade 2006, Examinador Lder do Projeto Excelncia na Pesquisa Tecnolgica da ABIPTI, alm de atuao como examinador em prmios setorias e regionais. Vicente Fernandes Tino mestre em Engenharia Eltrica, rea de concentrao Automao Industrial, pela Universidade Federal do Rio de Janeiro / COPPE, especialista em Gesto da Produo pelo Centro Integrado de Ensino S uperior do Amazonas e Engenheiro Eletricista pela Universidade Federal do Amazonas. S experincia profissional inclui o cargo de diretor tcnico ua da MAP Cardoso, Chefe da S ecretaria de Informtica do Tribunal Regional do Trabalho da 11 Regio, Diretor da MAP Motores, Pesquisador na rea de eficincia energtica e automao da produo da Fundao Andr Nunes Coelho, docncia em cursos de Administrao, S istemas da Informao e Engenharia de Produo, bem como consultoria na rea de Automao da Manufatura e Controle em diversas empresas.
Gerenciamento de projetos
2 Texto para estudo
2.1 Introduo
Um projeto um esforo temporrio empreendido para criar um produto, servio ou resultado exclusivo. [PMI 2004]. Temporrio significa que todos os projetos possuem um incio e um final definidos. O final alcanado quando os objetivos do projeto tiverem sido atingidos, quando se tornar claro que os objetivos do projeto no sero ou no podero ser atingidos ou quando no existir mais a necessidade do projeto e ele for encerrado. Temporrio no significa necessariamente de curta durao; muitos projetos duram vrios anos. Em todos os casos, no entanto, a durao de um projeto finita. Projetos no so esforos contnuos. [PMI 2004] Um projeto cria entregas exclusivas, que podem ser produtos, servios ou resultados, ou seja, todo produto, servio ou resultado gerado por um projeto diferente de outros produtos, servios ou resultados, mesmo que tenham semelhana ou contenham elementos repetitivos. Os projetos envolvem a realizao de algo jamais realizado anteriormente e logo nico. A elaborao progressiva uma caracterstica de projetos que integra os conceitos de temporrio e exclusivo. Elaborao progressiva significa desenvolver em etapas e continuar por incrementos. Um projeto progressivo porque medida que mais bem compreendido, ele progressivamente elaborado, ou seja, maior o detalhamento das caractersticas peculiares que o distinguem como nico [Dinsmore e Cavalieri 2003; PMI 2003]. Os projetos diferem da operao normal de uma organizao. Por meio deles podemos organizar atividades que no podem ser abordadas dentro dos limites operacionais normais da organizao. Os projetos so, portanto, freqentemente utilizados como um meio de atingir o plano estratgico de uma organizao, seja a equipe do projeto formada por funcionrios da organizao ou um prestador de servios contratado [PMI 2004] Um projeto para ser executado necessita ser gerenciado. S egundo Koontz e ODonnel [1980], gerenciar consiste em executar atividades e tarefas que tm como propsito planejar e controlar atividades de outras pessoas para atingir objetivos que no podem ser alcanados caso as pessoas atuem por conta prpria, sem o esforo sincronizado dos subordinados. S egundo o PMI, o gerenciamento de projetos a aplicao de conhecimento, habilidades, ferramentas e tcnicas s atividades do projeto a fim de atender aos seus requisitos. Os projetos esto sujeitos ao que se chama restrio tripla escopo, tempo e custo no gerenciamento das necessidades conflitantes do projeto. Ou seja, projeto de alta qualidade entregam o produto, servio ou resultado dentro do escopo, no prazo determinado e dentro do oramento. A relao entre esses fatores ocorre de tal forma que se um destes trs fatores mudar, pelo menos um dos outros fatores provavelmente ser afetado [PMI 2004].
2.2 O Gerente de projetos

O gerente de projetos a pessoa responsvel pela realizao dos objetivos do projeto. Gerenciar um projeto inclui: - Identificao das necessidades - Estabelecimento de objetivos claros e alcanveis - Balanceamento das demandas conflitantes de qualidade, escopo, tempo e custo - Adaptao das especificaes, dos planos e da abordagem s diferentes preocupaes e expectativas das diversas partes interessadas. Os gerentes de projetos precisam no s saber como trabalhar nos ambientes comerciais e de projetos como tambm necessitam estar bastante familiarizados com o campo de atuao do projeto [Verzuh 2000]. Especificamente os gerentes de projetos precisam ter qualificaes em trs reas diferentes: - Gesto de projetos conhecimento de habilidades e tcnicas para conduzir o projeto; - Gesto de negcios Habilidades necessrias a qualquer gerente, como negociao, finanas, recursos humanos, comunicao. - Tcnica Conhecimento tcnico do produto do projeto, ou do ambiente no qual o mesmo se desenvolve. O grau de exigncia de cada uma destas qualificaes ir variar de acordo com o tipo de projeto, a equipe envolvida, estrutura organizacional, objetivos e expectativas. O gerente do projeto possui vrias atividades e responsabilidades, como por exemplo: definir e controlar os objetivos do projeto; definir e controlar os requisitos do produto; definir e controlar os riscos do projeto; definir e avaliar os fatores crticos de sucesso do projeto; definir e avaliar os pontos fortes e pontos fracos do projeto; definir e controlar o cronograma; verificar o esforo, avaliar o projeto e a equipe com mtricas; alocar e gerenciar recursos (oramento, materiais, pessoas); definir prioridades; coordenar interaes entre os envolvidos no projeto; assegurar que os prazos e custos esto sendo mantidos dentro do planejado; assegurar que os produtos do projeto atendam aos critrios de qualidade e que estejam de acordo com os padres estabelecidos; formalizar a aceitao dos artefatos resultantes de cada fase do ciclo de vida do projeto; elaborar relatrios de avaliao e de acompanhamento da situao do projeto; participar de reunies de acompanhamento e de reviso do projeto. O gerente de projetos atualmente ganha destaque dentro das organizaes pela evoluo e relevncia do gerenciamento de projetos. A profisso de gerenciamento de projetos emergente e bastante promissora [Martins 2003; PMI 2004] Para Kerzner (1992) existem dez importantes habilidades inerentes ao gerente do projeto, definidas por meio de pesquisas e experincias (Tabela 1). Essas pesquisas demonstram que uma performance efetiva de gerenciamento de projetos est diretamente relacionada ao nvel de competncia em que estas habilidades sejam dominantes. Conforme o autor, importante que as caractersticas pessoais de gerenciamento destaquem as habilidades de operao, para formar um estilo de gerenciamento homogneo.
6
Habilidades Construo Equipes Liderana Resoluo de Conflito Competncia Tcnica Planejamento Organizao Empreendedor Administrao Suporte Gerencial Caractersticas de Capacidade de formar e gerenciar equipes de trabalho
Capacidade de influenciar a equipe e todos os envolvidos no projeto Capacidade de identificar e resolver os conflitos no mbito do projeto Capacidade de coordenar as aes tcnicas do projeto Capacidade de elaborar planos e execut-los. Capacidade de estabelecer os critrios de trabalho no mbito do projeto Capacidade de gerar e gerenciar negcios para o projeto. Capacidade de desenvolver tcnicas de controle, oramento, etc. Capacidade de gerenciar as interfaces com todos os envolvidos no projeto, principalmente com a alta administrao. Capacidade de estabelecer os recursos necessrios s vrias fases do projeto
Alocar Recursos
Tabela 1 Habilidades do Gerente de Projetos, segundo Kerzner (1992)
2.3 O ciclo de vida dos projetos

Para facilitar o gerenciamento do projeto ele deve ser dividido em fases que constituem seu ciclo de vida. O ciclo de vida do projeto serve para definir o incio e o fim do projeto e definem quais as atividades que devem ser realizadas em cada fase, e quais os recursos que devem estar envolvidos. Ele descreve o conjunto de processos que devem ser seguidos para que o projeto seja bem gerenciado [Dinsmore e Cavalieri 2003; PMI 2004]. s vezes o ciclo de vida do projeto confundido com o ciclo de vida do produto. O ciclo de vida do produto refere-se s fases que vo desde a identificao da necessidade ou da idia de se lanar um novo produto at a disposio final deste produto aps seu uso. Portanto, o ciclo de vida do produto pode conter vrios projetos, como o projeto do produto em si, o projeto de uma nova linha de produo para o produto, a campanha de marketing para lanamento. Muitas organizaes adotam a prtica de determinar um modelo de ciclo vida nico para todos os seus projetos, isto facilita o acompanhamento da alta direo em relao aos vrios projetos executados simultaneamente. O ciclo de vida de um projeto define as fases que conectam o inicio do projeto ao seu final. A transio de uma fase para a outra dentro do ciclo de vida de um projeto em geral envolve e normalmente definida por alguma forma de transferncia tcnica ou entrega. As entregas de uma fase geralmente so revisadas, para garantir que estejam completas e exatas, e aprovadas Gerenciamento de projetos
7 antes que o trabalho seja iniciado na prxima fase. No entanto, no incomum que uma fase seja iniciada antes da aprovao das entregas da fase anterior, quando os riscos envolvidos so considerados aceitveis. Essa prtica de sobreposio de fases, normalmente feita em seqncia, um exemplo da aplicao da tcnica de compresso do cronograma denominada paralelismo [PMI 2004]. As descries das fases do ciclo de vida podem ser muito genricas ou muito detalhadas, isto vai depender de cada organizao. Porm os ciclos de vida compartilham algumas caractersticas comuns: - As fases geralmente so seqenciais e existe algum documento ou evento que identifica o final de uma dada fase e o inicio da prxima. - Os custos do projeto e alocao de pessoal so baixos no inicio, atingem o seu valor mximo durante as fases intermediarias e decrescem de forma rpida nas fases finais. - As incertezas, e consequentemente os riscos do projeto no atingir seus objetivos, so altas no inicio do projeto e medida que o projeto avana as certezas se tornam mais claras e se pode vislumbrar o trmino do projeto. - O custo de mudanas e de correo de erros maior conforme a continuao do projeto. - A capacidade de influencia das partes interessadas de influenciarem nas caractersticas finais do produto do projeto e no custo do projeto maior na fase inicial e vai diminuindo de acordo com o avano do projeto. Embora muitos ciclos de vida do projeto possuam nomes de fases semelhantes com entregas semelhantes, poucos ciclos de vida so idnticos. Alguns podem ter quatro ou cinco fases, mas outros podem ter nove ou mais. reas de aplicao isoladas reconhecidamente apresentam variaes significativas. O ciclo de vida de desenvolvimento de software de uma organizao pode ter uma nica fase de projeto, enquanto outro pode ter fases diferentes para projeto arquitetural e detalhado. Os subprojetos tambm podem ter ciclos de vida do projeto distintos [PMI 2004]. De forma clssica o ciclo de vida do projeto definido em cinco fases distintas: iniciao; planejamento; execuo; controle e encerramento. A figura 1 ilustra estas fases.
Nvel de atividade
Iniciao
Controle Tempo
Figura 1 Fases do ciclo de vida do projeto Gerenciamento de projetos
Encerramento
Planejamento
Execuo
8 Fase de iniciao a fase inicial do projeto, quando uma necessidade identificada e transformada em um problemas a ser resolvido pelo projeto. onde as estratgias de conduo so identificadas e selecionadas. nesta fase que a misso e o objetivo do projeto so definidos. onde ocorre o detalhamento do que ser realizado no projeto, onde so elaborados os cronogramas, dependncias entre atividades, alocao de recursos, anlise de custos, etc., com o objetivo de se obter o detalhamento suficiente para que o projeto possa ser executado sem imprevisto ou dificuldades. Nesta fase tambm so elaborados os demais planos do projeto, como planos de comunicao, de gesto de configurao, riscos, qualidade. a fase da concretizao, onde tudo o que foi planejado anteriormente toma forma. nesta fase que aparecem os erros cometidos nas fases anteriores, tambm neste momento que ocorre a maior alocao de recursos, custo e esforo do projeto. a fase que ocorre paralelamente desde o planejamento at o encerramento do projeto. onde comparado o que foi planejado com o que est sendo realizado em tremo de custo, prazos, recursos, esforo de forma a se poder tomar aes para a correo dos rumos e proporcionar um realimentao rpida do projeto, evitando que os desvios afetem o sucesso do projeto.
Fase de planejamento
Fase de execuo
Fase de controle
Fase de quando ocorre a entrega dos ltimos produtos do projeto, os contratos, encerramento documentos e livros so encerrados, onde ocorre a verificao do projeto por terceiros ou internamente. Tambm nesta fase ocorre o levantamento das lies aprendidas, ou seja, o que deu errado e pode ser melhorado e o que deu certo e deve ser repetido em projetos futuros. Conforme mostrado na Figura 1 as fases no so estanques, havendo sobreposio entre elas, e tambm muitas vezes um projeto inicia uma nova fase sem que a anterior tenha sido oficialmente encerrada, desde haja a segurana com relao aos riscos envolvidos no projeto.
2.4 Processos de gerenciamento de projetos

Os processos de gerenciamento de projetos so apresentados como elementos distintos, com interfaces bem definidas. O Guia PMBOK descreve a natureza dos processos de gerenciamento de projetos em termos da integrao entre os processos, das interaes dentro deles e dos objetivos a que atendem. Esses processos so agregados em cinco grupos, definidos como os grupos de processos de gerenciamento de projetos: - Grupo de processos de iniciao. Define e autoriza o projeto ou uma fase do projeto. - Grupo de processos de planejamento. Define e refina os objetivos e planeja a ao necessria para alcanar os objetivos e o escopo para os quais o projeto foi realizado.
9 - Grupo de processos de execuo. Integra pessoas e outros recursos para realizar o plano de gerenciamento do projeto para o projeto. - Grupo de processos de monitoramento e controle. Mede e monitora regularmente o progresso para identificar variaes em relao ao plano de gerenciamento do projeto, de forma que possam ser tomadas aes corretivas quando necessrio para atender aos objetivos do projeto. - Grupo de processos de encerramento. Formaliza a aceitao do produto, servio ou resultado e conduz o projeto ou uma fase do projeto a um final ordenado. Os grupos de processos necessrios e seus processos constituintes so orientaes para a aplicao do conhecimento e das habilidades de gerenciamento de projetos adequados durante o projeto. Alm disso, a aplicao dos processos de gerenciamento de projetos a um projeto iterativa e muitos processos so repetidos e revisados durante o projeto. O gerente de projetos e a equipe do projeto so responsveis pela determinao de que processos dos grupos de processos sero empregados e por quem, alm do grau de rigor que ser aplicado execuo desses processos para alcanar o objetivo desejado do projeto [PMI 2004] Um grupo de processos inclui os processos de gerenciamento de projetos constituintes que esto ligados pelas respectivas entradas e sadas, ou seja, o resultado ou o produto de um processo se torna a entrada de outro processo. Os grupos de processos no so fases do projeto. Quando projetos grandes ou complexos podem ser separados em fases ou subprojetos distintos, como estudo de viabilidade, desenvolvimento de conceitos, projeto, elaborao de prottipo, construo, teste, etc., todos os processos do grupo de processos seriam normalmente repetidos para cada fase ou subprojeto [PMI 2004]. A Figura 2 mostra a interao de alto nvel entre os grupos de processos.
10
Figura 2 Resumo de alto nvel da interao entre os grupos de processos fonte: PMI 2004
2.4.1 Grupo de processos de iniciao

O Grupo de processos de iniciao constitudo pelos processos que facilitam a autorizao formal para iniciar um novo projeto ou uma fase do projeto. Por meio dos processos so desenvolvidas descries claras dos objetivos do projeto, incluindo as razes pelas quais um projeto especfico se constitui na melhor soluo alternativa para satisfazer os requisitos. Gerenciamento de projetos
11
Em projetos com vrias fases, os processos de iniciao so realizados durante fases subseqentes para validar as premissas e as decises tomadas anteriormente. O Grupo de processos de iniciao (Figura abaixo) inicia um projeto ou uma fase do projeto e as sadas definem a finalidade do projeto, identificam os objetivos e autorizam o gerente de projetos a iniciar o projeto. O Grupo de processos de iniciao inclui os seguintes processos de gerenciamento de projetos: Desenvolver o termo Este processo trata principalmente da autorizao do projeto ou, em um de abertura do projeto com vrias fases, de uma fase do projeto. o processo projeto necessrio para documentao das necessidades de negcios e do novo produto, servio ou outro resultado que deve satisfazer esses requisitos. Desenvolver a Este o processo necessrio para produzir uma definio preliminar de declarao do escopo alto nvel do projeto usando o termo de abertura do projeto junto com preliminar do projeto outras entradas para os processos de iniciao. Este processo aborda e documenta os requisitos do projeto e da entrega, os requisitos do produto, os limites do projeto, os mtodos de aceitao e o controle de alto nvel do escopo.
2.4.2 Grupo de processos de planejamento

O objetivo deste grupo de processos desenvolver o plano de gerenciamento do projeto. Esses processos tambm identificam, definem e amadurecem o escopo do projeto, o custo do projeto e agendam as atividades do projeto que ocorrem dentro dele. medida que forem descobertas novas informaes sobre o projeto, as dependncias, os requisitos, os riscos, as oportunidades, as premissas e as restries adicionais sero identificados ou resolvidos. A equipe do projeto deve usar as partes interessadas no planejamento do projeto, pois elas possuem habilidades e conhecimento que podem ser aproveitados no desenvolvimento do plano de gerenciamento do projeto e em quaisquer planos auxiliares. A equipe do projeto deve criar um ambiente no qual as partes interessadas possam contribuir de forma adequada. O Grupo de processos de planejamento facilita o planejamento do projeto entre vrios processos. O Grupo de processos de planejamento inclui os seguintes processos de gerenciamento de projetos: Desenvolver o plano de gerenciamento do projeto Este o processo necessrio para definir, preparar, integrar e coordenar todos os planos auxiliares em um plano de gerenciamento do projeto. O plano de gerenciamento do projeto se torna a principal fonte de informaes de como o projeto ser planejado, executado, monitorado e controlado, e encerrado. Este o processo necessrio para criar um plano de gerenciamento do escopo do projeto que documenta como o escopo do projeto ser definido, verificado e controlado e como a estrutura analtica do projeto ser criada e definida. Gerenciamento de projetos
Planejamento do escopo
12 Definio do escopo Este o processo necessrio para desenvolver uma declarao do escopo detalhada do projeto como base para futuras decises do projeto. Este o processo necessrio para subdividir as principais entregas do projeto e do trabalho do projeto em componentes menores e mais facilmente gerenciveis. Este o processo necessrio para identificar as atividades especficas que precisam ser realizadas para produzir as vrias entregas do projeto. Este o processo necessrio para identificar e documentar as dependncias entre as atividades do cronograma. Este o processo necessrio para estimar o tipo e as quantidades de recursos necessrios para realizar cada atividade do cronograma.
Criar EAP
Definio da atividade Seqenciamento de atividades Estimativa de recursos da atividade
Estimativa de Este o processo necessrio para estimar o nmero de perodos de durao da atividade trabalho que sero necessrios para terminar atividades do cronograma especficas. Desenvolvimento do cronograma Este o processo necessrio para analisar os recursos necessrios, restries do cronograma, duraes e seqncias de atividades para criar o cronograma do projeto. Este o processo necessrio para desenvolver uma aproximao dos custos dos recursos necessrios para terminar as atividades do projeto. Este o processo necessrio para agregar os custos estimados de atividades individuais ou pacotes de trabalho para estabelecer uma linha de base dos custos. Este o processo necessrio para identificar os padres de qualidade relevantes para o projeto e determinar como satisfaz-los. Este o processo necessrio para identificar e documentar funes, responsabilidades e relaes hierrquicas do projeto, alm de criar o plano de gerenciamento de pessoal. Este o processo necessrio para determinar as necessidades de informao e de comunicao das partes interessadas no projeto. Este o processo necessrio para decidir como abordar, planejar e executar as atividades de gerenciamento de riscos de um projeto.
Estimativa de custos
Oramentao
Planejamento da qualidade Planejamento de recursos humanos
Planejamento das comunicaes Planejamento do gerenciamento de riscos
13 Identificao de riscos Anlise qualitativa de riscos Este o processo necessrio para determinar os riscos que podem afetar o projeto e documentar suas caractersticas. Este o processo necessrio para priorizar riscos para anlise ou ao adicional subseqente atravs de avaliao e combinao de sua probabilidade de ocorrncia e impacto. Este o processo necessrio para analisar numericamente o efeito dos riscos identificados nos objetivos gerais do projeto. Este o processo necessrio para desenvolver opes e aes para aumentar as oportunidades e reduzir as ameaas aos objetivos do projeto. Este o processo necessrio para determinar o que comprar ou adquirir e quando e como fazer isso. Este o processo necessrio para documentar os requisitos de produtos, servios e resultados e identificar possveis fornecedores.
Anlise quantitativa de riscos Planejamento de respostas a riscos Planejar compras e aquisies Planejar contrataes
2.4.3 Grupo de processos de execuo

O Grupo de processos de execuo constitudo pelos processos usados para terminar o trabalho definido no plano de gerenciamento do projeto a fim de cumprir os requisitos do projeto. Este grupo de processos envolve a coordenao das pessoas e dos recursos, alm da integrao e da realizao das atividades do projeto de acordo com o plano de gerenciamento do projeto. Este grupo de processos tambm aborda o escopo definido na declarao do escopo do projeto e implementa as mudanas aprovadas. As variaes normais de execuo exigiro algum replanejamento. Essas variaes podem incluir duraes de atividades, produtividade e disponibilidade de recursos, e riscos no esperados. A maior parte do oramento do projeto ser gasta na realizao dos processos do Grupo de processos de execuo. O Grupo de processos de execuo inclui os seguintes processos de gerenciamento de projetos: Orientar e gerenciar a execuo do projeto Realizar a garantia da qualidade Este o processo necessrio para orientar as diversas interfaces tcnicas e organizacionais que existem no projeto para executar o trabalho definido no plano de gerenciamento do projeto. Este o processo necessrio para aplicar as atividades de qualidade planejadas e sistemticas para garantir que o projeto emprega todos os processos necessrios para atender aos requisitos. Este o processo necessrio para obter os recursos humanos necessrios para terminar o projeto.
Contratar ou mobilizar a equipe do projeto Desenvolver a
Este o processo necessrio para melhorar as competncias e a interao Gerenciamento de projetos
14 equipe do projeto Distribuio das informaes Solicitar respostas de fornecedores Selecionar fornecedores de membros da equipe para aprimorar o desempenho do projeto. Este o processo necessrio para colocar as informaes disposio das partes interessadas no projeto no momento oportuno. Este o processo necessrio para obter informaes, cotaes, licitaes, ofertas ou propostas. Este o processo necessrio para revisar ofertas, escolher entre possveis fornecedores e negociar um contrato por escrito com o fornecedor.
2.4.4 Grupo de processos de monitoramento e controle

O Grupo de processos de monitoramento e controle constitudo pelos processos realizados para observar a execuo do projeto, de forma que possveis problemas possam ser identificados no momento adequado e que possam ser tomadas aes corretivas, quando necessrio, para controlar a execuo do projeto. Esse monitoramento contnuo permite que a equipe do projeto tenha uma viso clara da sade do projeto e destaca as reas que exigem ateno adicional. O Grupo de processos de monitoramento e controle, alm de monitorar e controlar o trabalho que est sendo realizado dentro de um grupo de processos, tambm monitora e controla todo o esforo do projeto. O Grupo de processos de monitoramento e controle inclui os seguintes processos de gerenciamento de projetos:
Monitorar e controlar o trabalho do projeto
Este o processo necessrio para coletar, medir e disseminar informaes sobre o desempenho e avaliar as medies e as tendncias para efetuar melhorias no processo. Este processo inclui o monitoramento de riscos para garantir que os riscos sejam identificados no incio, que o andamento seja relatado e que planos de risco adequados estejam sendo executados. O monitoramento inclui emisso de relatrios de andamento, medio do progresso e previso. Os relatrios de desempenho fornecem informaes sobre o desempenho do projeto em relao a escopo, cronograma, custo, recursos, qualidade e risco. Este o processo necessrio para controlar os fatores que criam mudanas para garantir que essas mudanas sejam benficas, determinar se ocorreu uma mudana e gerenciar as mudanas aprovadas, inclusive o momento em que ocorrem. Esse processo realizado durante todo o projeto, desde a iniciao at o encerramento do projeto. Este o processo necessrio para formalizar a aceitao das entregas do projeto terminadas.
Controle integrado de mudanas
Verificao do escopo
15 Controle do escopo Este o processo necessrio para controlar as mudanas feitas no escopo do projeto. Este o processo necessrio para controlar as mudanas feitas no cronograma do projeto. O processo de influenciar os fatores que criam as variaes e controlar as mudanas no oramento do projeto. Este o processo necessrio para monitorar resultados especficos do projeto a fim de determinar se eles esto de acordo com os padres relevantes de qualidade e identificar maneiras de eliminar as causas de um desempenho insatisfatrio. Este o processo necessrio para acompanhar o desempenho de membros da equipe, fornecer feedback, resolver problemas e coordenar mudanas para melhorar o desempenho do projeto. Este o processo necessrio para coletar e distribuir informaes sobre o desempenho. Isso inclui relatrio de andamento, medio do progresso e previso. Este o processo necessrio para gerenciar a comunicao a fim de satisfazer os requisitos das partes interessadas no projeto e resolver problemas com elas. Este o processo necessrio para acompanhar os riscos identificados, monitorar os riscos residuais, identificar novos riscos, executar planos de respostas a riscos e avaliar sua eficincia durante todo o ciclo de vida do projeto. Este o processo necessrio para gerenciar o contrato e a relao entre o comprador e o fornecedor, analisar e documentar o desempenho atual ou passado de um fornecedor e, quando adequado, gerenciar a relao contratual com o comprador externo do projeto.
Controle do cronograma Controle de custos
Realizar o controle da qualidade
Gerenciar a equipe do projeto
Relatrio de desempenho
Gerenciar as partes interessadas
Monitoramento e controle de riscos
Administrao de contrato
2.4.5 Grupo de processos de encerramento

O Grupo de processos de encerramento inclui os processos usados para finalizar formalmente todas as atividades de um projeto ou de uma fase do projeto, entregar o produto terminado para outros ou encerrar um projeto cancelado. Este grupo de processos, quando terminado, verifica se os processos definidos esto terminados dentro de todos os grupos de processos para encerrar o projeto ou uma fase do projeto, conforme adequado, e estabelece formalmente que o projeto ou uma dada fase est concluda.
16 O Grupo de processos de encerramento inclui os seguintes processos de gerenciamento de projetos:
Encerrar o projeto
Este o processo necessrio para finalizar todas as atividades em todos os grupos de processos para encerrar formalmente o projeto ou uma fase do projeto. Este o processo necessrio para terminar e liquidar cada contrato, inclusive a resoluo de quaisquer itens em aberto, e encerrar cada contrato aplicvel ao projeto ou a uma fase do projeto.
Encerramento do contrato
2.4.6 Interaes entre processos

Os grupos de processos de gerenciamento de projetos esto ligados pelos objetivos que produzem. Em geral, as sadas de um processo se tornam entradas para outro processo ou so entregas do projeto. O Grupo de processos de planejamento fornece ao Grupo de processos de execuo um plano de gerenciamento do projeto e uma declarao do escopo do projeto documentado, e freqentemente atualiza o plano de gerenciamento do projeto conforme o projeto se desenvolve. Alm disso, os grupos de processos raramente so eventos distintos ou nicos; eles so atividades sobrepostas que ocorrem em diversos nveis de intensidade durante todo o projeto. A Figura 3 ilustra como os grupos de processos interagem e o nvel de sobreposio em momentos diferentes dentro de um projeto. S o projeto estiver dividido em fases, os grupos de processos iro interagir e dentro de uma fase do projeto e tambm podero atravessar vrias fases do projeto [PMI 2004].
Figura 3 - Interao de grupos de processos em um projeto. Fonte: PMI 2004
17
2.4.7 Mapeamento do processo de gerenciamento de projetos

A Tabela 2, a seguir, reflete o mapeamento dos 44 processos de gerenciamento de projetos nos cinco grupos de processos de gerenciamento de projetos e nas nove reas de conhecimento em gerenciamento de projetos. Cada um dos processos de gerenciamento de projetos necessrio mostrado no grupo de processos no qual ocorre a maior parte da atividade. Por exemplo, quando um processo que normalmente ocorre durante o planejamento reexaminado ou atualizado durante a execuo, ele ainda o mesmo processo que foi realizado no processo de planejamento, e no um novo processo adicional.
Grupos de processos de gerenciamento de projetos reas do conhecimento Processos de iniciao -Desenvolver o termo de abertura do projeto -Desenvolver a declarao do escopo preliminar do projeto Processos de planejamento -Desenvolver o plano de gerenciamento do projeto Processos de execuo -Orientar o e gerenciar a execuo do projeto Processos de monitoramento e controle -Monitorar e controlar o trabalho do projeto -Controle integrado de mudanas Processos de encerramento -Encerrar o projeto
Gerenciamento de integrao do projeto
Gerenciamento do escopo do projeto
-Planejamento do escopo -Definio do escopo -Criar EAP
-Verificao do escopo -Controle do escopo
Gerenciamento de tempo do projeto
-Definio de atividades -Seqenciamento de atividades -Estimativa de recursos da atividade -Estimativa de durao da atividade -Desenvolvimento do cronograma
-Controle do cronograma
Gerenciamento de custos do projeto
-Estimativa de custos -Oramentao
-Controle do custo
Gerenciamento da qualidade do projeto
-Planejamento da qualidade
-Realizar a garantia da qualidade
-Controle da qualidade
18
Gerenciamento de recursos humanos do projeto
-Planejamento dos recursos humanos -Contratar ou mobilizar a equipe do projeto -Desenvolver a equipe do projeto -Planejamento das comunicaes -Distribuio das informaes -Relatrio de desempenho -Gerenciar as partes interessadas -Planejamento do gerenciamento de riscos -Identificao de riscos -Anlise qualitativa de riscos -Anlise quantitativa de riscos -Planejamento de respostas a riscos -Monitoramento e controle de riscos -Gerenciar a equipe do projeto
Gerenciamento das comunicaes do projeto Gerenciamento de riscos do projeto
Gerenciamento de aquisies do projeto
-Planejar compras e aquisies -Planejar contrataes
-Solicitar respostas de fornecedores -Selecionar fornecedores
-Administrao de contrato
-Encerramento do contrato
Tabela 2 Mapeamento entre os processos de gerenciamento de projetos e os grupos de processos de gerenciamento de projetos e as reas de conhecimento. Fonte: PMI 2004
2.5 reas de conhecimento do gerenciamento de projetos

O gerenciamento de projetos de acordo com o Guia PMBOK 3. edio [PMI 2004], identifica e descreve as principais reas de conhecimento e prticas. Cada uma destas reas (no total de 9) descrita atravs de processos (no total de 39), e se refere a um aspecto a ser considerado dentro da gerncia de projetos. As reas de conhecimento de gerenciamento so: Gerenciamento de Integrao do Projeto, Gerenciamento de Escopo do Projeto, Gerenciamento do Tempo do Projeto, Gerenciamento do Custo do Projeto, Gerenciamento da Qualidade do Projeto, Gerenciamento de Recursos Humanos do Projeto, Gerenciamento de Comunicao do Projeto, Gerenciamento do Risco do Projeto e Gerenciamento de Contratao do Projeto. A no execuo de processos de uma rea afeta negativamente o projeto, pois o projeto um esforo integrado. Por exemplo, uma mudana de escopo quase sempre afeta o custo do projeto. Entretanto, ela pode ou no afetar a moral da equipe e a qualidade do produto [PMI 2004].
19
2.5.1 Gerenciamento de integrao do projeto

O gerenciamento de integrao do projeto inclui os processos e as atividades necessrias para identificar, definir, combinar, unificar e coordenar os diversos processos e atividades de gerenciamento de projetos dentro dos grupos de processos de gerenciamento de projetos. No contexto do gerenciamento de projetos, a integrao inclui caractersticas de unificao, consolidao, articulao e aes integradoras que so essenciais para o trmino do projeto, para atender com sucesso s necessidades do cliente e das partes interessadas e para gerenciar as expectativas. Os processos de gerenciamento de integrao do projeto incluem: Desenvolver o termo de abertura do projeto Desenvolver a declarao do escopo preliminar do projeto Desenvolver o plano de gerenciamento do projeto Orientar e gerenciar a execuo do projeto - desenvolvimento do termo de abertura do projeto que autoriza formalmente um projeto - desenvolvimento da declarao do escopo preliminar do projeto que fornece uma descrio de alto nvel do escopo
- documentao das aes necessrias para definir, preparar, integrar e coordenar todos os planos auxiliares em um plano de gerenciamento do projeto - execuo do trabalho definido no plano de gerenciamento do projeto para atingir os requisitos do projeto definidos na declarao do escopo do projeto - monitoramento e controle dos processos necessrios para iniciar, planejar, executar e encerrar um projeto para atender aos objetivos de desempenho definidos no plano de gerenciamento do projeto - reviso de todas as solicitaes de mudana, aprovao de mudanas e controle de mudanas nas entregas e nos ativos de processos organizacionais - finalizao de todas as atividades entre todos os grupos de processos do projeto para encerrar formalmente o projeto
Monitorar e controlar o trabalho do projeto
Controle integrado de mudanas
Encerrar o projeto.
2.5.2 Gerenciamento do escopo do projeto

O gerenciamento do escopo do projeto inclui os processos necessrios para garantir que o projeto inclua todo o trabalho necessrio, e somente ele, para terminar o projeto com sucesso. O gerenciamento do escopo do projeto trata principalmente da definio e controle do que est e do que no est includo no projeto. Os processos de gerenciamento do escopo do projeto incluem:
20 Planejamento do escopo - criao de um plano de gerenciamento do escopo do projeto que documenta como o escopo do projeto ser definido, verificado e controlado e como a estrutura analtica do projeto (EAP) ser criada e definida - desenvolvimento de uma declarao do escopo detalhada do projeto como a base para futuras decises do projeto - subdiviso das principais entregas do projeto e do trabalho do projeto em componentes menores e mais facilmente gerenciveis - formalizao da aceitao das entregas do projeto terminadas - controle das mudanas no escopo do projeto.
Definio do escopo
Criar EAP
Verificao do escopo Controle do escopo
2.5.3 Gerenciamento de tempo do projeto

O gerenciamento de tempo do projeto inclui os processos necessrios para realizar o trmino do projeto no prazo. Os processos de gerenciamento de tempo do projeto incluem: Definio da atividade - identificao das atividades especficas do cronograma que precisam ser realizadas para produzir as vrias entregas do projeto - identificao e documentao das dependncias entre as atividades do cronograma - estimativa do tipo e das quantidades de recursos necessrios para realizar cada atividade do cronograma - estimativa do nmero de perodos de trabalho que sero necessrios para terminar as atividades individuais do cronograma - anlise dos recursos necessrios, restries do cronograma, duraes e seqncias de atividades para criar o cronograma do projeto - controle das mudanas no cronograma do projeto.
Seqenciamento de atividades Estimativa de recursos da atividade Estimativa de durao da atividade Desenvolvimento do cronograma Controle do cronograma
2.5.4 Gerenciamento de custos do projeto

O gerenciamento de custos do projeto inclui os processos envolvidos em planejamento, estimativa, oramentao e controle de custos, de modo que seja possvel terminar o projeto dentro do oramento aprovado. Os processos de gerenciamento de custos do projeto incluem:
21 Estimativa de custos - desenvolvimento de uma aproximao dos custos dos recursos necessrios para terminar as atividades do projeto - agregao dos custos estimados de atividades individuais ou pacotes de trabalho para estabelecer uma linha de base dos custos - controle dos fatores que criam as variaes de custos e controle das mudanas no oramento do projeto.
Oramentao
Controle de custos
2.5.5 Gerenciamento da qualidade do projeto

O gerenciamento da qualidade do projeto inclui os processos e as atividades da organizao executora que determinam as responsabilidades, os objetivos e as polticas de qualidade, de modo que o projeto atenda s necessidades que motivaram sua realizao. Ele implementa o sistema de gerenciamento da qualidade atravs da poltica e dos procedimentos, com atividades de melhoria contnua dos processos conduzidas do incio ao fim, conforme adequado. Os processos de gerenciamento da qualidade do projeto incluem: Planejamento da qualidade Realizar a garantia da qualidade - identificao dos padres de qualidade relevantes para o projeto e determinao de como satisfaz-los - aplicao das atividades de qualidade planejadas e sistemticas para garantir que o projeto emprega todos os processos necessrios para atender aos requisitos. - monitoramento de resultados especficos do projeto a fim de determinar se eles esto de acordo com os padres relevantes de qualidade e identificao de maneiras de eliminar as causas de um desempenho insatisfatrio.
Realizar o controle da qualidade
2.5.6 Gerenciamento de recursos humanos do projeto

O gerenciamento de recursos humanos do projeto inclui os processos que organizam e gerenciam a equipe do projeto. A equipe do projeto composta de pessoas com funes e responsabilidades atribudas para o trmino do projeto. Embora seja comum falar-se de funes e responsabilidades atribudas, os membros da equipe devem estar envolvidos em grande parte do planejamento e da tomada de decises do projeto. O envolvimento dos membros da equipe desde o incio acrescenta especializao durante o processo de planejamento e fortalece o compromisso com o projeto. O tipo e o nmero de membros da equipe do projeto muitas vezes podem mudar conforme o projeto se desenvolve. Os membros da equipe do projeto podem ser chamados de pessoal do projeto. Os processos de gerenciamento de recursos humanos do projeto incluem:
22 Planejamento de recursos humanos - identificao e documentao de funes, responsabilidades e relaes hierrquicas do projeto, alm da criao do plano de gerenciamento de pessoal - obteno dos recursos humanos necessrios para terminar o projeto
Contratar ou mobilizar a equipe do projeto Desenvolver a equipe do projeto Gerenciar a equipe do projeto
- melhoria de competncias e interao de membros da equipe para aprimorar o desempenho do projeto - acompanhamento do desempenho de membros da equipe, fornecimento de feedback, resoluo de problemas e coordenao de mudanas para melhorar o desempenho do projeto.
2.5.7 Gerenciamento das comunicaes do projeto

O gerenciamento das comunicaes do projeto inclui os processos necessrios para garantir a gerao, coleta, distribuio, armazenamento, recuperao e destinao final das informaes sobre o projeto de forma oportuna e adequada. Os processos de gerenciamento das comunicaes do projeto fornecem as ligaes crticas entre pessoas e informaes que so necessrias para comunicaes bem-sucedidas. Os gerentes de projetos podem gastar um tempo excessivo na comunicao com a equipe do projeto, partes interessadas, cliente e patrocinador. Todos os envolvidos no projeto devem entender como as comunicaes afetam o projeto como um todo. Os processos de gerenciamento das comunicaes do projeto incluem: Planejamento das comunicaes Distribuio das informaes Relatrio de desempenho Gerenciar as partes interessadas - determinao das necessidades de informaes e comunicaes das partes interessadas no projeto - colocao das informaes necessrias disposio das partes interessadas no projeto no momento oportuno - coleta e distribuio das informaes sobre o desempenho, inclusive relatrio de andamento, medio do progresso e previso. - gerenciamento das comunicaes para satisfazer os requisitos das partes interessadas no projeto e resolver problemas com elas.
2.5.8 Gerenciamento de riscos do projeto

O gerenciamento de riscos do projeto inclui os processos que tratam da realizao de identificao, anlise, respostas, monitoramento e controle, e planejamento do gerenciamento de riscos em um projeto. Os objetivos do gerenciamento de riscos do projeto so aumentar a probabilidade e o impacto dos eventos positivos e diminuir a probabilidade e o impacto dos eventos adversos nos objetivos do projeto. Os processos de gerenciamento de riscos do projeto incluem: Gerenciamento de projetos
23
Planejamento do gerenciamento de riscos Identificao de riscos
- deciso de como abordar, planejar e executar as atividades de gerenciamento de riscos de um projeto
- determinao dos riscos que podem afetar o projeto e documentao de suas caractersticas - priorizao dos riscos para anlise ou ao adicional subseqente atravs de avaliao e combinao de sua probabilidade de ocorrncia e impacto - anlise numrica do efeito dos riscos identificados nos objetivos gerais do projeto - desenvolvimento de opes e aes para aumentar as oportunidades e reduzir as ameaas aos objetivos do projeto - acompanhamento dos riscos identificados, monitoramento dos riscos residuais, identificao dos novos riscos, execuo de planos de respostas a riscos e avaliao da sua eficcia durante todo o ciclo de vida do projeto.
Anlise qualitativa de riscos
Anlise quantitativa de riscos Planejamento de respostas a riscos Monitoramento e controle de riscos
2.5.9 Gerenciamento de aquisies do projeto

O gerenciamento de aquisies do projeto inclui os processos para comprar ou adquirir os produtos, servios ou resultados necessrios de fora da equipe do projeto para realizar o trabalho. Este captulo apresenta duas perspectivas de aquisio. A organizao pode ser o comprador ou o fornecedor do produto, servio ou resultados sob um contrato. O gerenciamento de aquisies do projeto inclui os processos de gerenciamento de contratos e de controle de mudanas necessrios para administrar os contratos ou pedidos de compra emitidos por membros da equipe do projeto autorizados. O gerenciamento de aquisies do projeto tambm inclui a administrao de qualquer contrato emitido por uma organizao externa (o comprador) que est adquirindo o projeto da organizao executora (o fornecedor) e a administrao de obrigaes contratuais estabelecidas para a equipe do projeto pelo contrato. Os processos de gerenciamento de aquisies do projeto incluem:
Planejar compras e aquisies Planejar contrataes
- determinao do que comprar ou adquirir e de quando e como fazer isso - documentao dos requisitos de produtos, servios e resultados, e identificao de possveis fornecedores
24 Solicitar respostas de fornecedores Selecionar fornecedores Administrao de contrato - obteno de informaes, cotaes, preos, ofertas ou propostas, conforme adequado - anlise de ofertas, escolha entre possveis fornecedores e negociao de um contrato por escrito com um fornecedor. - gerenciamento do contrato e da relao entre o comprador e o fornecedor, anlise e documentao do desempenho atual ou passado de um fornecedor a fim de estabelecer aes corretivas necessrias e fornecer uma base para futuras relaes com o fornecedor, gerenciamento de mudanas relacionadas ao contrato e, quando adequado, gerenciamento da relao contratual com o comprador externo do projeto - trmino e liquidao de cada contrato, inclusive a resoluo de quaisquer itens em aberto e o encerramento de cada contrato.
Encerramento do contrato
2.6 Estrutura organizacional para projetos

A estrutura organizacional determina como os projetos sero desenvolvidos dentro das organizaes, estes arranjos so influenciados principalmente pela natureza e pelos negcios da organizao, onde temos por um lado organizaes que s fazem trabalhos de projetos, como empresas de construo onde seus departamentos dedicam-se a projetos exclusivos, ou organizaes que so montadas para a viabilizao de um evento especfico como o PanAmericano, que aps a realizao do mesmo so desfeitas e tambm existem as empresas de produo contnua, onde impera a operao rotineira. Entretanto, as maiorias das organizaes conduzem operaes rotineiras e projetos. As organizaes que possuem uma estrutura funcional, ou no baseada em projetos, so principalmente aquelas voltadas para a fabricao de um bem ou para a execuo de um determinado servio. Nestas organizaes os projeto so voltados para implementao de um novo produto ou servio, ou seja, os projetos so visto como atividades de suporte. Nestas organizaes, geralmente, o gerente de projeto tem dificuldades para conduzir seus trabalhos, pois os projetos no fazem parte da lista de prioridades da organizao. Nas organizaes baseadas em projetos o trabalho totalmente voltado para projetos, e cada um destes projetos tem o seu prprio sistema de controles. A organizao atua como um grande organizador de projetos. Nestas organizaes os gerentes de projetos tm disponibilidade para atuarem em projetos, pois sua funo principal gerenciar projetos. Todos os funcionrios da organizao atuam em algum projeto e os gerentes de projetos tm total autoridade inclusive funcional sobre os membros de sua equipe. Nas estruturas organizacionais mistas ou matriciais, podem existir setores ou departamentos com a hierarquia totalmente funcional e ao mesmo tempo setores inteiros com estruturas voltadas completamente para projetos. Nestas organizaes as pessoas so alocadas nas operaes e nos projetos, porm a distribuio de foras entre o gerente funcional e o gerente do projeto varia de acordo com o tipo de organizao, a importncia dos projetos, o grau de especializao exigido e a Gerenciamento de projetos
25 complexidade do projeto. Os gerentes de projetos nestas organizaes podem ser membros de times funcionais ou at mesmo gerentes de projetos em tempo integral que respondem para o gerente de gerentes de projetos. Na tabela 3 podemos ver o grau de influncia da estrutura organizacional nos projetos.
Estrutura organizacional
Matricial Funcional Por projeto Fraca Balanceada Forte
Caractersticas do projeto
Autoridade do gerente de projetos
Pouca ou nenhuma
Limitada
Baixa a moderada
Moderada a alta
Alta e quase total
Disponibilidade recursos
de
Pouca ou nenhuma
Limitada
Baixa a moderada
Moderada a alta
Alta e quase total
Quem controla o oramento do projeto Funo do gerente de projetos
Gerente funcional
Gerente funcional
Misto
Gerente de projetos
Gerente de projetos
Tempo parcial
Tempo parcial
Tempo integral
Tempo integral
Tempo integral
Equipe administrativa gerenciamento projetos
do de
Tempo parcial
Tempo parcial
Tempo parcial
Tempo integral
Tempo integral
Tabela 3 Influncias da estrutura organizacional nos projetos. Fonte: PMI 2004
A organizao funcional clssica, mostrada na Figura 4, uma hierarquia em que cada funcionrio possui um superior bem definido. Os funcionrios so agrupados por especialidade, como produo, marketing, engenharia e contabilidade, no nvel superior. Nas organizaes o escopo do projeto geralmente restrito aos limites da funo. O departamento de engenharia em uma organizao funcional far o seu trabalho do projeto de modo independente dos departamentos de produo ou de marketing. Quando realizado o desenvolvimento de um novo produto em uma organizao puramente funcional, a fase de projeto do produto inclui somente pessoal do departamento de engenharia. Em seguida, quando surgirem questes sobre produo, elas sero passadas para o chefe de departamento no nvel hierrquico superior da organizao, que ir consultar o chefe do departamento de produo. O chefe do departamento de engenharia ento passar a resposta de volta para o gerente funcional de engenharia, no nvel hierrquico inferior o que pode causar atrasos, perda de foco e falta de prioridade para o projeto.
26
Figura 4 Organizao funcional Na organizao por projetos, mostrada na Figura 5, a seguir, os membros da equipe geralmente so colocados juntos. A maior parte dos recursos da organizao est envolvida no trabalho do projeto e os gerentes de projetos possuem grande independncia e autoridade. As organizaes por projeto em geral possuem unidades organizacionais denominadas departamentos, mas esses grupos se reportam diretamente ao gerente de projetos ou oferecem servios de suporte para os diversos projetos.
Figura 5 Organizao projetizada As organizaes matriciais, conforme mostrado nas Figuras 6, so uma combinao de caractersticas das organizaes funcional e por projeto. As matrizes fracas mantm muitas das caractersticas de uma organizao funcional e a funo do gerente de projetos mais parecida com a de um coordenador ou facilitador que com a de um gerente. De modo semelhante, as matrizes fortes possuem muitas das caractersticas da organizao por projeto, e podem ter gerentes de projetos em tempo integral com autoridade considervel e pessoal administrativo trabalhando para o projeto em tempo integral. Embora a organizao matricial balanceada reconhea a necessidade de um gerente de projetos, ela no fornece ao gerente de projetos autoridade total sobre o projeto e os recursos financeiros do projeto.
27
Figura 6 Organizao matricial fraca. Fonte: PMI 2004
Figura 7 Organizao matricial balanceada. Fonte: PMI 2004
Figura 8 Organizao matricial forte. Fonte: PMI 2004 A maioria das organizaes modernas envolve todas essas estruturas em vrios nveis, conforme mostrado na Figura 9 (Organizao composta). Por exemplo, at mesmo uma organizao fundamentalmente funcional pode criar uma equipe de projeto especial para cuidar de um projeto crtico. Essa equipe pode ter muita das caractersticas de uma equipe de projeto em uma Gerenciamento de projetos
28 organizao por projeto. A equipe pode incluir pessoal de diferentes departamentos funcionais trabalhando em tempo integral, pode desenvolver seu prprio conjunto de procedimentos operacionais e pode operar fora da estrutura hierrquica formal padro.
Figura 9 Organizao composta. Fonte: PMI 2004
2.7 Escritrio de projetos

Hoje em dia muitas organizaes procuram centralizar e coordenar o gerenciamento de seus vrios projetos por meio da utilizao de um escritrio de projetos (PMO Project Management Office do Ingls). O PMO tambm pode ser chamado de escritrio de gerenciamento de programas, escritrio de programas ou quartel general. A funo do PMO supervisionar o gerenciamento de projetos, programas ou uma combinao de ambos. Os PMOs podem operar de modo contnuo, desde o fornecimento de funes de apoio ao gerenciamento de projetos na forma de treinamento, software, polticas padronizadas e procedimentos, at o gerenciamento direto real e a responsabilidade pela realizao dos objetivos do projeto. Um PMO especfico pode receber uma autoridade delegada para atuar como parte interessada integral e um importante tomador de decises durante o estgio de iniciao de cada projeto, pode ter autoridade para fazer recomendaes ou pode encerrar projetos para manter a consistncia dos objetivos de negcios. Alm disso, o PMO pode estar envolvido na seleo, no gerenciamento e na realocao, se necessrio, do pessoal compartilhado do projeto e, quando possvel, do pessoal dedicado do projeto [PMI 2004]. De acordo com a estrutura organizacional o PMO pode ser basicamente de trs nveis [Vargas 2002]: - Projeto autnomo O escritrio de projetos separado das funes de operao da organizao. Ele designado para o gerenciamento de um projeto ou programa especifico e tem toda a responsabilidade quanto ao sucesso do projeto. - Project S upport Office o PMO que atua na esfera departamental, apoiando diversos projetos simultaneamente, fornecendo servios, ferramentas, controles de prazo, custo e qualidade. Algumas vezes tem a responsabilidade de fornecer os recursos tcnicos, metodologia de gerenciamento, compartilhamento do conhecimento, interface organizacional, buscando com que a organizao possua um centro de competncias em projetos. Gerenciamento de projetos
29 - Enterprise Project S upport Office - PMO que atua corporativamente, buscando tanto o alinhamento dos projetos com a estratgia corporativas quanto o gerenciamento estratgico dos projetos da organizao. S uas funes, alm das anteriores, so o planejamento estratgico dos projetos, a gesto dos projetos corporativos e interdepartamentais, a gesto do conhecimento, alm da interface entre as partes interessadas nos projetos. Um PMO pode existir em qualquer uma das estruturas organizacionais, inclusive nas que apresentam uma organizao funcional, sendo que a probabilidade de ocorrncia aumenta quanto mais projetizada for a estrutura organizacional.
2.8 Atividades durante o ciclo de vida do projeto

Como forma de ajudar no estabelecimento das atividades e no fluxo de aes que devem ocorrer durante o ciclo de vida de um projeto, a seguir so demonstradas as principais atividades a serem desenvolvidas durante cada fase. Estas atividades, apesar de estarem exemplificadas de forma seqencial, podem ocorrer mais de uma vez durante o projeto. Como exemplo isto, podemos afirmar que as fases de planejamento, execuo e controle so cclicas at o fim do projeto.
2.8.1 Fase de definio

2.8.1.1 DEFINIO DO PROBLEMA
Todo projeto tem como origem um problema ou uma oportunidade, ou seja, o projeto pode ser definido como o caminho que leva de um ponto A para um ponto B, onde este ponto A pode ser a situao atual da empresa, o modo de vida, o local onde se est, e o ponto seria o novo nvel de produo, uma nova situao de vida, o local onde se quer chegar. Desta forma a definio consiste em elicitar o problema a ser resolvido pelo projeto. Esta definio crtica, pois muitas vezes os projetos chegam a uma soluo correta para um problema errado. A partir da definio do problema que se pode chegar s possveis solues.
2.8.1.2 CRIAR O TERMO DE ABERTURA DO PROJETO (OU PROJECT CHARTER)

O termo de abertura do projeto o documento que autoriza formalmente um projeto. O termo de abertura do projeto concede ao gerente de projetos a autoridade para aplicar os recursos organizacionais nas atividades do projeto. Um gerente de projetos identificado e designado o mais cedo possvel no projeto. O gerente de projetos sempre deve ser designado antes do incio do planejamento e, de preferncia, enquanto o termo de abertura do projeto estiver sendo desenvolvido [PMI 2004]. Ele serve como uma linha de base para o trabalho do gerente do projeto. Contm diversas informaes sobre o projeto, incluindo as estimativas iniciais em relao a custos, prazos, recursos necessrios. Estes dados so geralmente preliminares e descritos em alto nvel pelos executivos da organizao, identificando as necessidades e interesses. S egundo o PMI (2004), o termo de abertura do projeto, diretamente ou referenciando outros documentos, deve abordar as seguintes informaes: - Requisitos que satisfazem as necessidades, desejos e expectativas do cliente, do patrocinador e de outras partes interessadas; - Necessidades de negcios, descrio de alto nvel do projeto ou requisitos do produto para o qual o projeto realizado; Gerenciamento de projetos
30 - Objetivo ou justificativa do projeto; - Gerente de projetos designado e nvel de autoridade atribuda; - Cronograma de marcos sumarizado; - Influncia das partes interessadas; - Organizaes funcionais e sua participao; - Premissas organizacionais, ambientais e externas; - Restries organizacionais, ambientais e externas; - Caso de negcios justificando o projeto, incluindo o retorno sobre o investimento; - Oramento sumarizado.
2.8.1.3 IDENTIFICAR E S ELECIONAR O GERENTE DO PROJETO

Nesta etapa deve ser designado o gerente do projeto, e a partir deste momento ele passa a ser o condutor do projeto e, por conseguinte de todos os processos que ocorrero no durante o projeto.
2.8.1.4 DEFINIR O OBJETIVO, JUSTIFICATIVA, O PRODUTO E AS ENTREGAS DO PROJETO.

Todo projeto deve ter seu objetivo bem definido, assim como a justificativa para a realizao do mesmo. Tambm devem ser especificados os produtos do projeto e as entregas a serem feitas. O objetivo aquilo que se quer chegar com termino do projeto. mensurvel e controlvel. Normalmente o objetivo definido por verbos de ao, acompanhados de definies numricas de tempo, custo e prazos. A justificativa a razo de ser do projeto, ou seja, o porqu a organizao est iniciando o projeto, quais os benefcios que se obtero do projeto, pode tambm ser denominado de misso do projeto. Produtos e entregas O produto o resultado obtido na concluso do projeto, pode ser um bem fsico (uma casa em um projeto de construo cvel) ou um intangvel (um software) porm que pode ser medido e verificado. As entregas representam os resultados parciais obtidos ao longo do projeto. Tm a finalidade de avaliar o progresso do projeto. Normalmente so definidos em termos de marcos ou etapas no cronograma.
2.8.1.5 DESENVOLVER A DECLARAO DO ESCOPO DO PROJETO

A declarao do escopo do projeto a definio do projetoo que precisa ser realizado. A declarao do escopo do projeto aborda e documenta as caractersticas e limites do projeto e seus produtos e servios associados, alm dos mtodos de aceitao e controle do escopo. Uma declarao do escopo do projeto inclui: - Objetivos do produto e do projeto - Caractersticas e requisitos do produto ou servio - Critrios de aceitao do produto - Limites do projeto - Entregas e requisitos do projeto Gerenciamento de projetos
31 - Restries do projeto - Premissas do projeto - Organizao inicial do projeto - Riscos iniciais definidos - Marcos do cronograma - EAP inicial - Estimativa aproximada de custos - Requisitos de gerenciamento de configurao do projeto - Requisitos de aprovao. A declarao do escopo preliminar do projeto desenvolvida a partir das informaes fornecidas pelo iniciador ou pelo patrocinador. A equipe de gerenciamento de projetos refina mais a declarao do escopo preliminar do projeto para obter a declarao do escopo do projeto. O contedo da declarao do escopo do projeto ir variar dependendo da rea de aplicao e complexidade do projeto e poder incluir alguns ou todos os componentes identificados acima. Durante as fases subseqentes de projetos com vrias fases, a declarao do escopo preliminar do projeto valida e refina, se necessrio, o escopo do projeto definido para essas fases.
2.8.2 Fase de Planejamento

2.8.2.1 DESENVOLVER O PLANO DE GERENCIAMENTO DO PROJETO
O processo Desenvolver o plano de gerenciamento do projeto inclui as aes necessrias para definir, coordenar e integrar todos os planos auxiliares em um plano de gerenciamento do projeto.. Esse processo resulta em um plano de gerenciamento do projeto que atualizado e revisado por meio do processo Controle integrado de mudanas. O plano de gerenciamento do projeto define como o projeto executado, monitorado, controlado e encerrado. Ele pode ser um documento nico ou ser composto de vrios planos, de acordo com organizao. O contedo do plano de gerenciamento do projeto ir variar dependendo da rea de aplicao e complexidade do projeto. Esse plano inclui: - Os processos de gerenciamento de projetos selecionados pela equipe de gerenciamento de projetos - O nvel de implementao de cada processo selecionado - As descries das ferramentas e tcnicas que sero usadas para realizar esses processos - Como os processos selecionados sero usados para gerenciar o projeto especfico, inclusive as dependncias e interaes entre esses processos e as entradas e sadas essenciais. - Como o trabalho ser executado para realizar os objetivos do projeto - Como as mudanas sero monitoradas e controladas - Como o gerenciamento de configurao ser realizado
32 - Como a integridade das linhas de base da medio de desempenho ser mantida e utilizada - A necessidade e as tcnicas de comunicao entre as partes interessadas - O ciclo de vida do projeto selecionado e, para projetos com vrias fases, as fases associadas do projeto - As principais revises de gerenciamento em relao a contedo, extenso e tempo para facilitar a abordagem de problemas em aberto e de decises pendentes. O plano de gerenciamento do projeto pode ser sumarizado ou detalhado e pode ser constitudo por um ou mais planos auxiliares e outros componentes. Cada um dos planos auxiliares e componentes detalhado at o nvel necessrio para o projeto especfico. Esses planos auxiliares incluem, mas no se limitam a: - Plano de gerenciamento do escopo do projeto - Plano de gerenciamento do cronograma - Plano de gerenciamento de custos - Plano de gerenciamento da qualidade - Plano de melhorias no processo - Plano de gerenciamento de pessoal - Plano de gerenciamento das comunicaes - Plano de gerenciamento de riscos - Plano de gerenciamento de aquisies. Esses outros componentes incluem, mas no se limitam a: - Lista de marcos. - Calendrio de recurso. - Linha de base do cronograma. - Linha de base dos custos. - Linha de base da qualidade. - Registro de riscos.
2.8.2.2 CRIAR A ESTRUTURA ANALTICA S TRUCTURE)
DO
PROJETO EAP (WBS WORK BREAKDOWN
A EAP tem como finalidade definir as entregas e os pacotes de trabalho do projeto, com o objetivo de definir e organizar o escopo do projeto. A EAP subdivide o trabalho do projeto em partes menores e mais facilmente gerenciveis, em que cada nvel descendente da EAP representa uma definio cada vez mais detalhada do trabalho do projeto. A EAP representa o trabalho especificado na declarao do escopo do projeto atual aprovada. Os componentes que compem a EAP auxiliam as partes interessadas a visualizar as entregas do projeto. Na figura 10 est exemplifica a decomposio da EAP at o nvel de pacote de trabalho. Gerenciamento de projetos
33 Algumas das caractersticas da EAP so: - permitir a visualizao da contribuio de cada pacote de trabalho (work package) para o projeto principal; - permite o direcionamento das equipes, dos recursos e das responsabilidades; - determina quais materiais sero necessrios para a execuo de cada pacote; - determina o custo fina do projeto a partir do custo de cada pacote ou entrega. O nvel de pacote de trabalho o nvel mais baixo na EAP e o ponto no qual o custo e o cronograma do trabalho podem ser estimados de forma confivel. O nvel de detalhe dos pacotes de trabalho ir variar de acordo com o tamanho e complexidade do projeto.
Figura 10 Exemplo de EAP com ramos decompostos at o nvel de pacote de trabalho Para a correta elaborao da EAP, Xavier [2003] recomenda seguir os dez mandamentos da EAP: 1- Cobiars a EAP do teu prximo Antes da elaborao da EAP do projeto deve ser verificada a forma de estruturao da EAP de projetos semelhantes, outros projetos da organizao, literatura e tambm devem ser consultados outros profissionais de gerenciamento de projetos. 2- Todos os subprodutos devem estar explicitamente includos na EAP, inclusive os necessrios ao gerenciamento do projeto O subproduto que no estiver explicito na EAP no faz parte do escopo do projeto. O conceito de subproduto do projeto tambm inclui os servios (treinamento, teste, alinhamento, instalao, etc.). Devemos verificar se os subprodutos necessrios para o gerenciamento do projeto foram inclusos na EAP. Gerenciamento de projetos
34 3- No usars nomes em vo No devem ser utilizados nomes vagos para os elementos da EAP, que gerem duvidas semnticas a respeito de qual subproduto est sendo implementado. No deve ser indicado o processo de gerao dos mesmos, mas sim o resultado desse processo. 4- Guardars a descrio dos pacotes de trabalho no dicionrio da EAP - Os subprodutos devem ser claramente definidos no dicionrio da WBS para que fique bem explcito o trabalho a ser realizado. O dicionrio da EAP o documento que define ou descreve o trabalho a ser realizado em cada pacote de trabalho da EAP. 5 Decompors at um nvel de detalhe (pacote de trabalho) que permita o planejamento e controle do trabalho necessrio para sua entrega O planejamento e controle incluem: escopo, tempo, custo e risco. 6 No decompors em demasia de forma a que os custos de planejamento e controle no tragam o benefcio correspondente Planejar e controlar em seu tempo e custo associado a este trabalho. Assim a decomposio dever ser feita de acordo com a necessidade de cada projeto. 7 Honrars o pai - Cada elemento da WBS deve contribuir para o subproduto do elemento pai ao qual est subordinado. Verifique se os elementos filhos so realmente partes do elemento pai. 8 Decompors de forma que ao descer um nvel na EAP, a soma dos subprodutos dos elementos filhos corresponde ao subproduto do elemento pai (regra dos 100%) Ao decompor um subproduto nenhuma parte dele deve ser esquecida. A soma dos produtos componentes deve ser equivalente ao subproduto que foi decomposto. 9 No decompors em somente um subproduto - Um elemento da EAP no pode ter somente um filho, caso isto ocorra, deve ser verificado o esquecimento de algum elemento, co no haja esquecimento desnecessria a representao do elemento filho. 10 No repetirs o mesmo elemento como componente de mais de um subproduto Um elemento filho no pode ter mais de um pai. Podemos ter elementos com o mesmo nome compondo subprodutos diferentes, mas cada um com significado diferente. Criar o dicionario da EAP O dicionrio da EAP um documento complementar da EAP. O contedo detalhado dos componentes contidos em uma EAP, inclusive pacotes de trabalho e contas de controle, pode ser descrito no dicionrio da EAP. Para cada componente da EAP, o dicionrio da EAP inclui um cdigo do identificador de conta, uma declarao do trabalho, a organizao responsvel e uma lista de marcos do cronograma. A informao adicional sobre um componente da EAP pode incluir informaes de contrato, requisitos de qualidade e referncias tcnicas para facilitar o desempenho do trabalho. A informao adicional sobre uma conta de controle poderia ser um nmero de cobrana. A informao adicional sobre um pacote de trabalho pode incluir uma lista das atividades associadas do cronograma, os recursos necessrios e uma estimativa de custos. S o feitas referncias cruzadas de cada componente da EAP, conforme adequado, para outros componentes da EAP no dicionrio da EAP.
35
2.8.2.3 DEFINIO DE ATIVIDADES PARA OS ELEMENTOS DA EAP

Aps a definio da EAP devem ser geradas as atividades ou tarefas necessrias para a execuo de cada pacote de trabalho. As atividades so os componentes de trabalho fundamentais de um projeto. Elas so menor nvel da EAP e, em conseqncia, a menor subdiviso necessria para completar um projeto. S o executas de acordo com a natureza do projeto. As atividades podem ocorrer de forma seqencial ou simultaneamente. Os principais tipos de atividades so: - Atividades do cronograma (Activity) S as atividades relacionadas diretamente ao trabalho o executado dentro do projeto, estas atividades esto associadas s estimativas de custo, recursos e durao. - Marcos (Milestones) S atividades que representam um evento, o trmino ou inicio de uma o fase do projeto. S erve tambm para identificar as entregas. Elas no possuem durao, recursos e custos. - Atividade-resumo (S ummary Activities) S atividades que agregam um dado grupo de o atividades, tambm chamadas de subatividades. Servem para fazer a totalizao de custos, datas e recursos das atividades a elas pertencentes. - Atividades de superviso (Level of Effort) S atividades utilizadas para alocar os recursos o destinados a coordenao ou gerenciamento do projeto. Nestas atividades so relacionados somente os recursos, e elas no influenciam no planejamento, so atividades cuja durao varia de acordo com a durao do projeto.
2.8.2.4 DEFINIR A DURAO DAS ATIVIDADES

A determinao da durao das atividades consiste em estimar a quantidade de esforo necessrio para a execuo da mesma. O tempo de durao do projeto ser resultado da soma de todas as duraes das atividades componentes do mesmo. A definio de durao da atividade exige que a quantidade de esforo de trabalho necessria para terminar a atividade do cronograma seja estimada, que a quantidade prevista de recursos a ser aplicada para terminar a atividade do cronograma seja estimada e que o nmero de perodos de trabalho necessrio para terminar a atividade do cronograma seja determinado. Todos os dados e premissas que do suporte estimativa de durao so documentados para cada estimativa de durao da atividade. Na definio de durao da atividade deve-se levar em conta o tipo de atividade e qual a influencia do recurso na mesma. Existem atividades denominadas Atividades Orientadas para Recursos (Resource dependent) so atividade cujo nmero de recursos alocado influencia na durao da mesma, por exemplo, se um pedreiro constri uma parede em 10 dias, ao colocarmos dois pedreiros ela provavelmente ser construda em 5 dias, ou seja, a durao da mesma depender da disponibilidade dos recursos, utilizada quando os recursos podem trabalhar de forma independente em uma mesma atividade. Outro tipo de atividade chamada de Atividade de Durao Fixa (Task dependent) so as atividades que independente do nmero de recursos alocados ela tero a mesma durao, por exemplo, um treinamento de cinco dias de durao, demorar o mesmo tempo com cinco ou dez alunos em sala de aula. Ou ainda, se uma mulher leva Gerenciamento de projetos
36 nove meses para dar a luz a uma criana, no adianta colocarmos nove mulheres que a criana no nascer em um ms. Este tipo de atividade utilizada quando mltiplos recursos necessitam trabalhar juntos para a execuo da mesma. Estimativa por analogia E determinao da durao de uma atividade por analogia significa a utilizao da durao real de uma atividade anterior semelhante de um cronograma como base para a estimativa da durao de uma atividade futura. Ela freqentemente usada para estimar a durao do projeto quando existe uma quantidade limitada de informaes ou poucos detalhes sobre o projeto. Para a execuo deste tipo de estimativa deve ser utilizada a opinio de especialistas, a base histrica de projetos da organizao e a prpria equipe de projeto, que deve ter a especializao e experincia necessria. Estimativa paramtrica A estimativa das duraes das atividades pode ser determinada quantitativamente multiplicando a quantidade de trabalho a ser realizado pelo valor da produtividade. Por exemplo, a quantidade de paginas que uma impressora imprime por hora a produtividade a ser utilizada para determinar o tempo de impresso de uma quantidade de publicaes ou o tempo para se construir um muro determinado a partir a quantidade de metros que podem ser executados por hora por pedreiro. As quantidades totais de recursos so multiplicadas pelas horas de mo-de-obra por perodo de trabalho ou pela capacidade de produo por perodo de trabalho e divididas pelo nmero de recursos que est sendo aplicado para determinar a durao da atividade em perodos de trabalho. Anlise de PERT (What-if Analysis) A anlise de PERT, ou What-if analysis, consiste na estimativa de durao das atividades, por meio de cenrios otimistas, pessimistas e mais provveis. A durao da atividade se dar por meio do calculo da mdia ponderada das trs estimativas. Os pesos de cada estimativa podem variar de acordo com o projeto, com o conhecimento do produto do projeto e com a experincia dos estimadores. A relao mais comum de 1, 4 e 1 para as respectivas estimativas otimista, mais provvel e pessimista. Deste modo,
Durao
1 Opt. 4 Est 1 Pes 6
Onde
Opt = durao otimista Est = durao mais provvel Pes = durao pessimista
A anlise PERT permite uma maior preciso nas estimativas de durao das atividades.
37
2.8.2.5 DEFINIR O SEQENCIAMENTO DAS ATIVIDADES

O objetivo do seqenciamento das atividades identificar e documentar os relacionamentos lgicos entre as atividades para a determinao do cronograma. As atividades do cronograma podem ser seqenciadas logicamente usando as relaes de precedncia adequadas, alm de antecipaes e atrasos intencionalmente provocados, para dar suporte ao desenvolvimento posterior de um cronograma do projeto realista e alcanvel. Tipos de inter-relacionamento As atividades podem se relacionar de vrias formas, as mais usuais so: - Termino para incio (finish to start) A iniciao da atividade sucessora depende do trmino da atividade predecessora. Por exemplo, s podemos erguer as paredes de uma casa aps o trmino das fundaes. Este o tipo mais comum de relacionamento.
Predecessora
Sucessora
- Trmino para trmino (finish to finish) - O trmino da atividade sucessora depende do trmino da atividade predecessora. Por exemplo, pode-se decidir comear o projeto antes da sua aprovao, porm o projeto s poder terminar aps a aprovao do mesmo.
Predecessora
Sucessora
- Incio para incio (start to start) - A iniciao da atividade sucessora depende da iniciao da atividade predecessora. Por exemplo, em uma pintura de varias salas de um prdio, aps a preparao da primeira sala, tanto a equipe de preparao quanto a equipe de pintura podem trabalhar simultaneamente. Este tipo de reposio de tarefas reduz a durao total do projeto.
Predecessora
Sucessora
38
- Incio para trmino (start to finish) - O trmino da atividade sucessora depende da iniciao da atividade predecessora. Por exemplo, quando se esta instalando uma central telefnica nova, somente podemos comear a atividade de desligar a central antiga, aps a central nova estiver em pleno funcionamento. Esta relao pouco usual nos projetos.
Predecessora
Sucessora
Antecipao e atraso entre atividades Diversas atividades em um projeto necessitam de um intervalo de tempo para seu inicio aps o trmino da atividade predecessora. Por exemplo, atividades de secagem, cura, envelhecimento, necessitam de um tempo para a execuo das atividades restantes. Este atraso chamado de lag. Outras atividades podem ser antecipadas para se conseguir ganhar tempo no projeto, permitindo a realizao de atividade em paralelo. A tcnica de reduzir a durao do projeto por meio de adiantamentos chamada de fast tracking. Rede PERT Um modo de demonstrar graficamente os inter-relacionamentos entre as atividades se d por meio das redes PERT (Program Evaluation and Review Technique). A utilizao da rede PERT permite o entendimento do relacionamento e da interdependncia entre as atividades de uma forma simples. Porm pode apresentar dificuldades para projetos muitos grandes e no mostra a relao visual entre as duraes das atividades. Existem duas abordagens diferentes para a representao das atividades de um projeto por meio da rede PERT. AOA (Activity on Arrow) neste diagrama as atividades so representadas por setas que ligam um estado inicial a um estado final.
39
Figura 11 Rede PERT AOA AON (Activity on Node) - As atividades neste diagrama so representadas por ns entre as setas. o digrama mais utilizado, sendo gerado pelos programas de computador destinados ao gerenciamento de projetos.
Figura 12 Rede PERT AON Diagrama de Gantt O diagrama de Gantt, ou diagrama de barras, uma forma de representao do cronograma que utiliza barras horizontais em uma escala de tempo. O comprimento das barras est relacionado durao das atividades e as linhas ligando as barras representam as relaes entre as atividades. Gerenciamento de projetos
40 A utilizao do diagrama de Gantt permite um entendimento simples do projeto, dentro de uma escala de tempo bem definida, assim como permite a visualizao de atrasos.
Figura 13 Diagrama de Gantt Alocar recursos nas atividades Aps o seqenciamento das atividades necessrio identificar, selecionar e alocar os recursos nas atividades. Recursos so todas as pessoas, materiais de consumo e equipamentos necessrios para a realizao da atividade. Os recursos so geralmente divididos em recursos humanos (engenheiros, pintores, programadores, etc.), recursos materiais (areia, componentes eletrnicos, papel, material de consumo, etc.) e equipamentos (computadores, escavadeira, fogo, etc.). Quando da escolha do recurso deve se levar em conta a disponibilidade do mesmo, seu custo, a capacidade e qualidade, entre outros requisitos. Os recursos devem ser alocados a cada atividade do projeto, esta alocao servir de base para o clculo de oramentos e custos do projeto, assim como esta a nica maneira de gerenciar a disponibilidade e a alocao de cada recurso no projeto. Conciliao de recursos Aps a alocao dos recursos nas atividades existe a necessidade de verificar se os mesmos no esto com sua carga de trabalho superior ao seu limite mximo, esta verificao importante para se ter o cronograma mais realista possvel e tambm para garantir que os recursos alocados tero capacidade para realizar suas atividades. Para se resolver o problema de superalocao do recurso pode-se optar pela substituio de mesmo por outro, que possua qualificao equivalente para a realizao de trabalho e que esteja disponvel no perodo de conflito. Uma outra forma a troca de escala de trabalho ou a alocao do recurso em regime de horas-extras durante o perodo de superalocao, porm em qualquer Gerenciamento de projetos
41 destas duas alternativas deve-se levar em conta a perda de produtividade em decorrncia do cansao, os aspectos legais e os custos adicionais. A forma mais comum de conciliao atrasar as atividades segundo critrios de prioridades, restries ou durao com vistas a deixar a utilizao dos recursos em um nvel constante durante perodos de tempo do trabalho do projeto. Este nivelamento frequentemente resulta no atraso do trmino do projeto. No existe a melhor maneira de se conciliar os recursos. Cada situao deve ser estudada e buscada a melhor estratgia para a resoluo dos conflitos.
2.8.2.6 CLCULO DO CAMINHO CRTICO (CPM CRITICAL PATH METHOD)

O caminho crtico do projeto constitudo pelas atividades mais importantes do projeto. Qualquer atraso nas atividades constituintes do caminho crtico leva ao atraso no projeto. Uma outra forma de definirmos caminho crtico como o caminho com folga de tempo zero. O caminho crtico, em uma rede, o caminho mais longo do projeto. As atividades que compem o caminho crtico so chamadas de atividade crticas e, caso sofram algum atraso, inevitavelmente levaro a atrasos no projeto. As atividades no crticas, no tm efeito direto sobre a durao do projeto, desde que seu atraso no ultrapasse a folga determinada da mesma. Data de incio mais cedo IMC (ES - Early Start Date). data de incio mais cedo possvel na qual uma atividade pode ser iniciada, com base na lgica de rede do cronograma, na data dos dados e nas restries do cronograma. As datas de incio mais cedo podem mudar conforme o projeto se desenvolve e o plano de gerenciamento do projeto alterado. Data de incio mais tarde IMT (LS - Late Start Date). o momento mais tarde possvel no qual uma atividade do cronograma pode ser iniciada com base na lgica de rede do cronograma, na data de trmino do projeto e em quaisquer restries atribudas s atividades do cronograma sem, entretanto, levar ao atraso na data de trmino do projeto. Data de trmino mais cedo TMC (EF - Early Finish Date) o momento mais cedo possvel no qual uma atividade do cronograma pode ser terminada, com base na lgica de rede do cronograma, na data dos dados e nas restries do cronograma. As datas de trmino mais cedo podem mudar conforme o projeto se desenvolve e o plano de gerenciamento do projeto alterado. TMC = IMA + D Onde, TMC IMA D = Trmino mais cedo = Incio mais cedo = Durao estimada Gerenciamento de projetos
42
Data de trmino mais tarde TMT (LF - Late Finish Date). o momento mais tarde possvel no qual uma atividade do cronograma pode ser terminada com base na lgica de rede do cronograma, na data de trmino do projeto e em quaisquer restries atribudas s atividades do cronograma sem levar ao atraso na data de trmino do projeto. TMT = IMT + D Onde, TMT IMT D = Trmino mais tarde = Incio mais tarde = Durao estimada
Folga livre FL (FF - Free Float) o tempo permitido para atraso de uma atividade do cronograma sem atrasar o incio mais cedo de qualquer uma das atividades sucessoras do cronograma. Folga total FT (TF - Total Float) o atraso total permitido para a data de incio de uma atividade do cronograma sem atrasar a data de trmino do projeto ou violar uma restrio do cronograma, podendo a mesma causar atrasos no incio mais cedo das atividades sucessoras do cronograma, desde que estas no estejam no caminho crtico. calculada pela diferena entre as datas de incio mais cedo e as data de trmino mais cedo, ou seja: FT = TMT IMC - D Onde, FT = folga total
TMT = Trmino mais tarde IMC D = Incio mais cedo = Durao estimada
Aps se determinarem todas as datas do cronograma e as folgas, ento construdo o caminho crtico, que so as atividades com folga zero.
43
2.8.2.7 DESENVOLVER O CRONOGRAMA DO PROJETO

Aps o estabelecimento dos recursos, duraes e relaes de interdependncia entre as atividades, pode-se ento determinar qual a data de incio e trmino das mesmas por meio do estabelecimento do cronograma do projeto. Este cronograma pode ser apresentado de diversas formas, as mais comuns so: - Rede PERT - Tabelas com lista de atividade e seqncias - Grficos de Gantt - Grfico de marcos
O cronograma pode ser desenvolvido utilizando softwares para gerenciamento de projetos, que permitem as vrias visualizaes ou combinao das mesmas.
2.8.2.8 CLCULO DE CUSTOS DAS ATIVIDADES E DO PROJETO

A oramentao o processo de agregar os custos estimados das atividades individuais ou dos pacotes de trabalho para a determinao dos custos do projeto. O custo de uma dada atividade ser a composio dos custos dos recursos envolvidos na atividade, chamados de custos diretos, com os custos de superviso, instalaes e outros, chamados de custos indiretos. O clculo dos custos do projeto pode ser feito por meio do uso da EAP. O custo de uma fase ou de um pacote de trabalho ser a soma dos custos das atividades necessrias para esta fase ou pacote de trabalho. O custo total do projeto ser ento a soma dos custos de suas fases ou pacotes de trabalho, esta estimativa chamada de estimativa Botton Up.
$ 23500
$ 7600
$ 3000
$ 12900
$ 4400
$ 3200
$ 7500
$ 5400
$ 1900
$ 2500
$ 3000
$ 4500
$ 1200
$ 700
Figura 14 - Utilizao da EAP para clculo do custo do projeto
44
2.8.3 Fase de Execuo e Controle

2.8.3.1 REALIZAR A REUNIO DE LANAMENTO DO PROJETO
A reunio de lanamento do projeto pode ser considerada como o marco do fim do planejamento e incio da execuo do projeto. Mesmo o planejamento ocorrendo vrias vezes durante o projeto, este primeiro planejamento serve de linha de base para todo o projeto. Nesta reunio devem estar presentes todos os envolvidos no projeto, os planos so apresentados, os papis definidos, as estratgias de gerenciamento e de comunicao so explicitadas. Esta reunio pode tambm ser chamada de reunio de kick off.
2.8.3.2 EXECUO DOS PACOTES DE TRABALHO

A execuo dos pacotes de trabalho se d por meio da execuo das atividades relativas a cada pacote, a etapa de materializao do planejamento, todas as falhas que o ocorreram nas fases anteriores se tornaro evidentes. A execuo do pacote de trabalho considerada concluda quando ocorre a entrega (delivery). A entrega qualquer resultado do trabalho que pode ser verificvel, sendo facilmente mensurvel, tangvel pelos executantes e tem sua concluso identificvel de maneira simples e direta. Quando todos os pacotes de trabalho so finalizados e suas respectivas entregas so realizadas, ento tmse o fim do projeto. Execuo de atividades de suporte Juntamente com as atividades relacionadas a execuo dos pacotes de trabalho, so necessrias outras atividades para que o projeto possa ser executado e acompanhado com eficcia. Segundo o PMBOK [PMI 2004], algumas das atividade de suporte so: Comunicaes O gerente do projeto passa 90% de seu tempo se comunicando durante o projeto, por isto importante o cuidado com o fluxo de informaes, a distribuio da informao ao pblico necessitado no momento certo, da maneira correta e pelo meio correto, de acordo com o plano de comunicaes do projeto. Recursos Humanos Nesta etapa deve ser dada prioridade ao desenvolvimento da equipe, por meio de treinamentos, capacitaes, planos de carreiras e recompensas, atividades adequadas ao perfil, estilo de liderana de acordo com a situao encontrada e com a maturidade do subordinado, levando que o sucesso do projeto seja o sucesso das pessoas que compem o time do projeto. Qualidade Nesta etapa do projeto ocorre o que foi planejado no plano de qualidade, havendo atividades de controle de qualidade, com a finalidade de verificar os produtos do projeto e as atividades de garantia da qualidade, com a finalidade de termos a correta execuo dos processos. Suprimentos Na fase de execuo realizada a maioria das atividades relacionadas ao suprimento, com a ocorrncia da seleo de fornecedores, qualificao dos mesmos, execuo e controle dos contratos, de acordo com o plano de gerenciamento de suprimentos.
45
2.8.3.3 AVALIAR O DESEMPENHO DO PROJETO

O desempenho do projeto pode ser acompanhado de diversas maneiras, por meio de varincia e tendncias, por exemplo. A anlise do valor agregado (Earned Value Analysis) um das melhore tcnicas de avaliao. Ela responsvel pelo acompanhamento financeiro de todo o projeto, A anlise do valor agregado tem como foco a relao entre os custos reais consumidos e o trabalho realizado no projeto, buscando comparar o que foi atingido pelo projeto em relao ao gasto financeiro pra atingir aquele resultado. Esta anlise ajuda o gerente a controlar os custos juntamente com o cronograma do projeto, pois o acompanhamento por s uma desta variveis deixa o gerente com s metade da viso do projeto. O controle do desempenho por meio da anlise do valor agregado apresenta vrios termos, como: COTA - Custo orado do trabalho agendado (Budgeted C of Work S ost cheduled - BCWS) o oramento autorizado atribudo ao trabalho agendado que ser realizado para a atividade do cronograma ou componente da estrutura analtica do projeto, ou seja, o custo do oramento que deveria ter sido gasto at a data em que se est calculando o projeto. COTR - Custo orado do trabalho realizado (Budgeted C of Work Performed - BCWP) o valor ost do trabalho terminado expresso em termos do oramento aprovado atribudo a esse trabalho para uma atividade do cronograma ou componente da estrutura analtica do projeto. quanto do oramento deveria ter sido gasto at o momento em que se est calculando o projeto, levando em conto o trabalho que foi realizado at o momento. Tambm chamado de Valor Agregado (Earned Value EV). CRTR - Custo real do trabalho realizado (Actual C of Work Performed - ACWP) S os custos ost o totais realmente incorridos e registrados na realizao do trabalho executado durante um determinado perodo de tempo para uma atividade do cronograma ou um componente da estrutura analtica do projeto. O custo real s vezes pode representar somente as horas de mode-obra direta, somente os custos diretos ou todos os custos, inclusive custos indiretos. Anlise de variao de custo e prazo VC - Variao de custos (Cost Variance - CV). a diferena algbrica entre o valor agregado (VA) ou custo previsto (COTR) e o custo real (CRTR). VC = COTR - CRTR. Um valor positivo indica uma condio favorvel, ou um custo abaixo do previsto, e um valor negativo indica uma condio desfavorvel, ou seja, o projeto est atrasado em termos de custo.
46
COTA CRTR
COTR
Figura 15 Comportamento do CRTR, COTA e COTR ao longo do tempo para um dado projeto. VP - Variao de prazos (Schedule Variance - SV). a medida do desempenho de prazos em um projeto. a diferena algbrica entre o valor agregado (VA), ou COTR e o valor planejado, ou COTA. VP = COTR - COTA. S VP for positivo o projeto est adiantado em termos de custos, se for e negativo o projeto estar atrasado em termos de custos. Esses dois valores, a VC e o VP, podem ser convertidos em indicadores de eficincia para refletir o desempenho de custos e de prazos de qualquer projeto. IDC - ndice de desempenho de custos (C Performance Index - CPI) - a medida da eficincia de ost custos em um projeto. a relao entre o valor agregado (VA) e os custos reais (CR). Um valor de IDC menor que 1.0 indica um estouro nos custos estimados. Um valor de IDC maior que 1.0 indica custos estimados no atingidos.
IDC
VA CR
ou IDC
COTR CRTR
IDP - ndice de desempenho de prazos (S chedule Performance Index - SPI) - a medida da eficincia do cronograma em um projeto. a relao entre o valor agregado (VA) e o valor planejado (VP). Um IDP maior ou igual a 1.0 indica uma condio favorvel e um valor menor que 1.0 indica uma condio desfavorvel. O IDP usado, em adio ao andamento do cronograma, para prever a data de trmino e s vezes usado junto com o IDC para prever as estimativas de trmino do projeto.
IDP
VA VP
ou IDP
COTR COTA
47
2.8.3.4 PREVISES
A previso inclui a realizao de estimativas ou prognsticos de condies futuras do projeto com base nas informaes e no conhecimento disponveis no momento da previso. As previses so geradas, atualizadas e refeitas com base nas informaes sobre o desempenho do trabalho fornecidas conforme o projeto executado e desenvolvido. Para as atividades de previso so utilizados os seguintes conceitos: PAC (Plan at Completion) a durao prevista para o projeto (baseline project finish). TAC (Time at C ompletion) a durao projetada para o projeto, a relao entre a data prevista PAC e o SPI.
TAC
PAC SPI
DAC (Delay at Completion) a diferena entre a durao prevista PAC e a durao projetada TAC para o projeto. DAC = PAC - TAC BAC (Budget at Completion) o custo orado para o projeto (baseline budget) EAC (Estimate at Completion) o custo previsto final para o projeto. VAC (Variation at Completion) a diferena entre o custo orado BAC e o custo final do projeto EAC. VAC = BAC - EAC Existem trs maneiras de se avaliar os custos finais de um projeto. A primeira no leva em conta os resultados anteriores, e que a partir deste momento o projeto retornar ao seu oramento. Neste caso a previso de custo final do projeto ser: EAC = Oramento COTR + CRTR A segunda forma considera que a tendncia identificada no IDC (CPI) se manter nas atividades restantes. A frmula utilizada para esta estimativa :
EAC
Oramento COTR IDC
CRTR
A terceira maneira de avaliao considera tanto o ndice de desempenho de custos (IDC ou CPI), quanto o ndice de desempenho de prazos (IDP ou S sendo mais sensvel a variaes, tanto PI), para mais quanto para menos nestes ndices. Esta estimativa calculada da seguinte forma:
EAC
Oramento COTR IDCxIDP
CRTR
2.8.3.5 CONTROLAR AS MUDANAS DO PROJETO

Todo o controle do projeto gira em torno desta etapa. O objetivo desta etapa garantir que o que foi planejado est sendo executado, e caso ocorram mudanas no plano, o papel do gerente garantir que as mesmas tragam benefcios para o projeto. As mudanas devem ser controladas para que possa ser mantida a integridade das linhas de base de desempenho do projeto e devem ser coordenadas para garantir o beneficio do todo. Gerenciamento de projetos
48 A organizao necessita ter um processo estabelecido para controle de mudanas, visando garantir a rastreabilidade da mudana exigida com os pacotes de trabalho em execuo ou j entregues, os custos associados mudana, o nvel de exigncia da aprovao de acordo com a criticidade da mudana solicitada. A cada solicitao de mudana a equipe do planejamento deve ser envolvida para anlise de impacto da mesma e para a deciso de sua viabilidade de execuo.
2.8.3.6 VERIFICAR A CONCLUSO DE TODOS OS PACOTES DE TRABALHO

Nesta etapa so verificadas se todas as atividades dos pacotes de trabalho foram realizadas e se todas as entregas foram processadas. Caso no haja mais nenhum pacote de trabalho para ser entregue, procede-se fase de finalizao. Caso contrrio, realiza-se o prximo pacote de trabalho.
2.8.4 Fase de finalizao

2.8.4.1 VALIDAR O RESULTADO DO PROJETO COM O CLIENTE
Aps a entrega de todos os pacotes de trabalho, parte-se para avaliar o resultado do projeto junto ao cliente para obter o aceite do mesmo. Esta avaliao busca verificar se o resultado do projeto corresponde com o que foi especificado para o mesmo, fornecendo desta forma um subsdio para o aceite do projeto. Existem diversas formas de se proceder esta avaliao, podem ser feitas auditorias de primeira ou de segunda parte, testes de aceitao, acompanhamento de lote piloto ou outras formas concordadas durante a fase de planejamento do projeto. Como resultado desta fase obtm-se um documento formal declarando o aceite do projeto por parte de cliente, garantindo o fim da responsabilidade do executante sobre o produto do projeto, exceto para os casos de garantia e assistncia tcnica previsto em contratos.
2.8.4.2 REALIZAR O LEVANTAMENTO DAS LIES APRENDIDAS

Esta etapa de grande importncia para a equipe do projeto, pois proporciona o aprendizado, neste evento so levantados os problemas detectados quando do aceite do projeto, para que se investiguem as causas e se possam tomar aes corretivas para evitar a reincidncia do problema em futuros projetos. Podem ser utilizadas folhas de verificao para o levantamento de questes como o que no se sabia antes do projeto e que foi aprendido? O que se faria da mesma forma? O que se faria de forma diferente? Quais as dificuldades superadas? O que deu certo de deve ser repetido? O que deu errado e deve ser evitado? A lista de perguntas deve ser extensa tanto quanto a cultura de aprendizado est presente na organizao.
2.8.4.3 ENCERRAR CONTRATOS

Antes do encerramento do projeto, todos os contratos celebrados durante o mesmo devem ser encerrados. Este tipo de procedimento evita que pendncias do projeto fiquem ativa aps o encerramento do mesmo.
49
2.8.4.4 DESMOBILIZAR O TIME DO PROJETO

Deve-se desmobilizar todo o time do projeto antes do encerramento do mesmo, com sua respectiva estrutura de suporte, este passo deve ser dado com relativas ateno, pois no podemos deixar pessoas alocadas no projeto aps o trmino de suas atividades para no onerar os custos desnecessariamente, e tambm manter o foco do time no projeto quando o mesmo est chegando ao final e o pessoal j est preocupado ou comeando a tomar contatos com o prximo projeto em que vai atuar, este equilbrio exige muita ateno do gerente de projeto. Encerrar o projeto Aps todas as atividades de encerramento terem sido concludas, cabe ao gerente do projeto, tomar providencias para que se guarde a memria do projeto, nos repositrios da organizao e o projeto seja arquivado no rol dos casos de sucesso da organizao.
2.9 Concluses
O gerenciamento no deve ser praticado de maneira ad hoc, mas por meio da aplicao de conhecimentos, habilidades, ferramentas e tcnicas, onde se destacam as recomendaes do PMI, atravs do Guia PMBOM Com o uso de metodologias, a implantao da cultura de projetos . pode ser realizada para garantir a aplicao dos princpios de gerenciamento de projetos de forma padronizada buscando atender da melhor forma s necessidades das organizaes. S egundo Kerzner [2001] alcanar a excelncia de gerenciamento de projetos ou mesmo a maturidade pode no ser possvel sem o uso de processos repetitivos que podem ser usados no projeto. Estes processos repetitivos so referidos como a metodologia de gerenciamento de projetos, onde o contnuo uso desta metodologia aumentar drasticamente as chances de sucesso de uma organizao. Gerenciar projetos com eficincia constitui-se no apenas um grande desafio dos dias atuais, mas o fator crtico para o sucesso e para a sobrevivncia das empresas. Gerenciar projetos com eficincia requer um esforo de conscientizao das empresas em adotar metodologias de gerenciamento de projetos e treinar sua equipe e principalmente os seus gerentes dos projetos. Estas organizaes, se possvel, devem manter e suportar uma nica metodologia para gerenciamento de projetos. Neste cenrio, o gerente do projeto, capacitado, aquele que tem melhores condies de ver as necessidades do projeto. Ele deve ser um profissional treinado para usar uma metodologia de gerenciamento de projetos e aplic-la de forma eficiente. Ele deve ser alocado o mais cedo possvel ao projeto. Ao gerente devem ser dados autorizao formal e apoio visvel da alta administrao para que ele possa desempenhar bem o seu papel de gestor buscando o sucesso do projeto e a excelncia no gerenciamento.
50
3 Material Complementar
3.1 Estudo de caso - MPAR
O projeto Papagaio trata-se do desenvolvimento de um novo rdio de comunicao ttica que ser utilizado pelo exrcito em campo. Trata-se de um rdio tipo manpack. O mesmo possui um mecanismo de criptografia via software e sua mecnica deve suportar grandes impactos. Para o seu desenvolvimento foi contratada a mpar Servios Tecnolgicos. Trimestralmente na mpar ocorre a reunio de reviso de projetos, onde o Diretor de Engenharia rene-se com os gerentes e lderes de grupos de projetos e com os gerentes funcionais para saber o andamento dos projetos de grande porte, que so considerados estratgicos para a empresa. uma oportunidade que os gerentes tm para o compartilhamento do conhecimento, discusso dos problemas que causam impactos aos projetos, os riscos e as oportunidades. O relatrio de situao de projeto apresentado alta direo, utilizando um modelo de apresentao corporativo que deve ser seguido por todos. O S Carlos Costa, Diretor de Engenharia, conhecido na empresa pela sua objetividade, senso r. crtico e por exigir um alto nvel de desempenho de seus colaboradores. Esta reunio era muito importante para o Andr Campos, gerente do projeto Papagaio, pois sendo este projeto o foco da reunio, ele sabia que todos os olhos estariam voltados para ele. Para isto, ele havia se preparado muito bem, revisado junto com sua equipe a planilha de acompanhamento de custos e o cronograma. Estava tudo sob controle. Andr iniciou sua exposio lembrando da importncia do projeto para a empresa e tambm para o pas, pois ele implicava na absoro de uma nova tecnologia que tornaria o pas independente da tecnologia estrangeira e possibilitaria a exportao desta nova tecnologia. Em seguida, discorreu sobre o andamento do projeto, mostrando que todos os milestones (marcos) tinham sido atingidos na data planejada e que as despesas estavam 4,7 % abaixo do orado para a fase em que se encontrava. Na seqncia, apresentou os principais eventos e as lies aprendidas nos ltimos meses. Andr encheu o peito e afirmou que provavelmente esta era a primeira vez que um projeto dentro da mpar estava abaixo do oramento e dentro do cronograma, considerando a execuo de mais de 60% do mesmo. O grfico de Gant mostrava uma linha de corte na data da reunio com os marcos alcanados em azul marinho. Ao trmino de sua exposio, Andr concluiu que o projeto no podia estar em melhor forma, sem problemas e totalmente sob controle. O S Carlos tirou seus culos e esfregou r. os olhos com o polegar e indicador, sinal este que revelava quando ele estava satisfeito, e ento afirmou que era um alvio saber que pelo menos um projeto estava sob controle. A seguir, o S Geraldo Coelho, chefe do departamento de projetos mecnicos, se pronunciou e, r. antes de comear a passar seus slides, afirmou que achou bastante estranho o fato de Andr informar que o projeto estava em dia, pois havia duas semanas que ele estava esperando os desenhos das placas e as especificaes para que sua equipe pudesse elaborar o projeto mecnico do rdio. Na verdade, at poucos instantes, antes de entrar na reunio, o seu grupo no havia recebido qualquer desenho do grupo de hardware, responsvel pelo desenho das placas e, segundo Juliana Dias, responsvel pela equipe do lay out, estes desenhos somente estariam Gerenciamento de projetos
51 prontos talvez em trs semanas. Andr lanou um olhar fulminante em direo Juliana, que foi logo se defendendo, dizendo para Andr no olhar para ela, mas sim para Mrio Jorge, pois at aquele momento o pessoal de Mrio no havia liberado o esquema eltrico para que ela conseguisse comear a trabalhar no lay out. Mario Jorge fingiu-se de morto e evitou olhar para Andr. Prevendo o que viria pela frente, Juliana afirmou que se Mrio entregasse o esquema eltrico nesta semana, seu grupo tentaria priorizar o Papagaio, em detrimento de outros projetos, para conseguir entregar a documentao completa para o pessoal da mecnica em duas semanas. Geraldo continuou sua exposio mostrando as conseqncias advindas do atraso, porm afirmou que se o pessoal do Mrio e da Juliana conseguisse terminar o esquema eltrico e entregar o layout em duas semanas, seria possvel recuperar duas semanas com o pessoal trabalhando em horas extras. A cada slide que Geraldo apresentava Andr parecia mais enfurecido e encarando seus colaboradores Juliana e Mrio, que tentavam ignorar a presso do chefe. Carlos: Andr, quero saber se estas atividades esto no caminho crtico, pois no ms que vem tenho a reunio com o comando do exrcito para mostrar a situao do projeto j fechando o rosto e passando a mo na cabea, em sinal de comeo de exploso. E voc Mrio, vai conseguir entregar o esquema eltrico nesta semana para que a Juliana faa o lay out e possa enviar para o pessoal da mecnica? Mrio: Quando chegar a minha vez de expor eu exponho a situao... Carlos: Ento acho melhor voc comear a falar! Geraldo: Esperem um pouco, por favor! Tem mais um ponto que quero esclarecer, antes de passar a palavra para o Mrio. Juliana: Eu, de minha parte, vou dar meu jeito para cumprir o prazo. S no posso fazer milagres! Geraldo: que a gente no pode esquecer que todo este atraso vai acarretar um aumento do oramento da minha ordem de servios em torno de $ 20 mil em horrio normal e $ 32 mil, se tivermos que utilizar horas-extras. Andr: Como que isso? Geraldo: Ora camarada, estou com quatro engenheiros alocados para este projeto, que esto h duas semanas s olhando para o vento, e pelo jeito eles vo passar mais quatro semanas s esperando. Faa a o clculo a $ 18 a hora... Andr: Mas quer dizer que voc est querendo me cobrar por pessoas que no esto trabalhando no projeto? Geraldo: Claro, quando voc me passou a solicitao de servio, liberei a ordem de servio da minha equipe a partir da data em que voc mostrou no cronograma que necessitaria dos servios deles e lembre-se que voc enfatizou naquela ocasio a importncia estratgica do projeto. O qu que eu poderia fazer? Garanto que voc no gostaria que eu colocasse o pessoal em outro projeto e ficssemos sem ningum para executar o seu. No tenho gente sobrando e nem folga no meu oramento para ficar segurando o pessoal indefinidamente. Meu irmo! Voc solicitou, eu disponibilizei o pessoal para o projeto, portanto, o projeto paga por eles. Eu no tenho culpa se vocs no liberam os desenhos ou qualquer coisa para que o meu pessoal possa trabalhar? Gerenciamento de projetos
52 Carlos: Andr, pelo que entendi estes gastos no foram contabilizados. Ento o seu projeto no anda to bem financeiramente... Mrio: Bom... antes de mais nada, realmente eu ainda no passei o esquema eltrico para o pessoal da Juliana... Andr: Mas como? Se na reunio de duas semanas atrs vocs reportaram que tanto o esquema eltrico quanto o lay out estavam em dia? Tenho aqui comigo os relatrios e agora tenho uma surpresa destas! Juliana: verdade, mas voc vira uma fera e faz um escndalo cada vez que a gente ultrapassa uma data-alvo, exige relatrios escritos, planos de contingncia, reunies e reunies... Mrio: S falar no palavreado pouco educado. Mas no lhe informamos porque estvamos em certos que conseguiramos eliminar o rudo provocado pelo circuito de RF. Na simulao funcionou bem! Se tivesse funcionado na prtica, estaramos barrigando s uma semana ou duas. Juliana: E o nosso pessoal poderia tentar recuperar este atraso e liberar para a mecnica. Andr: Voc est me dizendo que ainda no terminou a implementao do circuito de RF? Mrio: , eu sei. Pensava que a soluo deste problema fosse trivial e, o mais importante, que fosse trabalhar no esquema e no circuito de controle. Andr: Caramba! Voc est me dizendo que aquele rudo ainda persiste? Voc me disse que o problema havia sido resolvido h mais de um ms? Mrio: Eu no imaginava que este problema fosse to cabeludo, ns estvamos mais preocupados em liberar o esquema eltrico, e tambm que esse rudo fosse por causa do micro controlador que estvamos utilizando e da protoboard, mas mesmo com o novo circuito micro controlador o problema ainda persiste. Andr: Mas voc garantiu que com a adio deste novo circuito o problema seria resolvido... Mrio: , na modelagem e na simulao a soluo parecia perfeita. Andr: P! Quer dizer que aumentamos o custo da B.O.M. em $ 5 e no resolvemos o problema? Carlos: Andr, ningum me informou que o produto ficaria mais caro. Ns sabemos que o cliente limitou o custo da B.O.M. e no aceita nenhum aumento! Andr: que eu no queria deix-lo preocupado, pensava que depois dos testes de prottipo poderamos trabalhar na reduo dos custos do produto. Geraldo: Ei! No podemos esquecer que qualquer alterao aps o teste do prottipo pode acarretar na alterao da mecnica e consequentemente... Juliana: Eu sei, mas estamos trabalhando para que as alteraes eltricas no acarretem em alteraes nas dimenses das placas. Mrio: Mas no podemos afirmar isto at resolvermos o problema do circuito de RF. Andr: Estou vendo que tenho muitos pontos a serem fechados... Juliana: S voc pagar horas extras creio que o nosso pessoal consiga reduzir o tempo de e confeco do layout. Gerenciamento de projetos
53 Mrio: S quero lembrar, antes que me peguem para Cristo, o que eu disse quando estvamos na fase de estimativas. Que necessitaramos de mais tempo, pelo menos mais dois meses alm do que voc tinha estimado. Trata-se de uma nova tecnologia que no dominvamos e que as coisas poderiam dar errado. Andr: L vem voc! S empre a mesma coisa: necessita do dobro do tempo e de mais pessoas. S eu fosse atender cada um de vocs, o Papagaio s falaria depois que meu filho de dois anos e entrasse no exrcito! Carlos: Chega! Pelo que estou vendo este Papagaio est mais para periquito e no vai falar nunca! Pessoal, agora hora de vocs se juntarem e acharem a soluo. Quero uma prestao de contas detalhada, juntamente com o relato da situao real do projeto e um plano para ver se salvamos este paciente. Espero ver tudo isto daqui a uma semana, quando continuaremos esta reunio. Aps a sada de Carlos da sala, os demais foram saindo em silncio. Andr foi o ltimo a sair, caminhou at sua sala tentando entender onde foi que ele errou. Como que aquele que seria o seu melhor dia virou um pesadelo. QUESTES PARA DEBATE 1) 2) 3) 4) 5) Qual a atitude de Andr em relao aos seus colaboradores Mrio e Juliana? Andr tem culpa pelas falhas de Mrio? Geraldo est agindo corretamente ao cobrar de Andr um servio que no foi executado? O que voc faria se fosse Andr? O que voc faria se fosse o Sr. Carlos Costa?
54
3.2 Estudo de Caso: Fox Meyer

Adaptado de: The FoxMeyer Drugs' Bankruptcy: Was it a Failure of ERP? Judy E. Scott, The University of Texas at Austin, Judy.Scott@bus.utexas.edu
Sumrio Este um estudo de caso interpretativo da implantao do ERP das FoxMeyer Drugs baseado em estruturas empricas e nos modelos de riscos em projetos de software e de escalas de projetos. As implicaes do estudo oferecem sugestes em como evitar a falha na implantao de ERPs. Introduo A FoxMeyer Drugs era uma companhia de $5 bilhes e o quarto maior distribuidor de produtos farmacuticos dos Estados Unidos antes do fiasco. Com o objetivo de usar a tecnologia para aumentar a eficincia, foi iniciado em 1993 o projeto Delta III. A FoxMeyer conduziu uma pesquisa de mercado e avaliao de produtos e decidiu pela compra do S R/ 3 em dezembro desse ano. A AP FoxMeyer tambm decidiu pela compra da soluo de automatizao de armazns de um fabricante chamado Pinnacle, e escolheu a Andersen Consulting para a integrao e implementao dos dois sistemas. A execuo do projeto Delta III ocorreu durante o perodo de 1994 e 1995. De acordo com Christopher Cole, CIO da Pinnacle, o fracasso da FoxMeyer no foi uma falha da automatizao. No foi uma falha do software comercial por si mesmo. Foi uma falha da gerenciamento (Jesitus, 1997). Talvez a gerncia tivesse expectativas irreais. A gerncia esperava que a tecnologia fosse uma bala de prata? (Markus e Benjamin 1997a, 1997b). Na realidade, era o oposto. A FoxMeyer foi falncia em 1996, e iniciou em 1998 um processo responsabilizando a S AP, vendedor de ERP, assim como a Andersen Consulting, seu integrador do S AP, pela sua falncia e exigindo $500 milhes de cada (Caldwell 1998, Stein 1998). Riscos do projeto O projeto Delta III da FoxMeyer Drugs era um projeto de alto risco por diversas razes. Para anlise dos risco vamos utilizar a estrutura desenvolvida para identificar riscos de projetos de software (Keil, Cule, Lyytinenand S chmidt 1998), esta estrutura classifica os riscos do projeto da FoxMeyer em (1) patrocnio do cliente, (2) escopo e requisitos, (3) execuo e (4) ambiente. Primeiramente, o patrocnio do cliente baseia-se no compromisso da alta gerncia e dos usurios. Na FoxMeyer, embora o compromisso da gerncia snior fosse elevado, os depoimentos colhidos revelaram que alguns usurios no estavam comprometidos. De fato, havia um problema de moral entre os empregados dos armazns. Isto no era surpresa, uma vez que a automatizao dos armazns, feita pela Pinnacle, integrada com a implementao do S R/ 3 representava uma AP ameaa para seus empregos. Com o fechamento de trs armazns, o incio da operao do primeiro armazm automatizado foi um desastre. Os trabalhadores desmotivados no prestavam ateno ao controle do inventrio e as ordens no eram preenchidas corretamente. E, para piorar, os erros ocorreram enquanto o novo sistema enfrentava problemas com o volume de transaes. Nesta operao perdeu-se em torno de $34 milhes de inventrio(Jesitus 1997). Gerenciamento de projetos
55 Em segundo lugar , o escopo do projeto representava um risco. A FoxMeyer era o que chamamos de early adopter do S R/ 3, ou seja, ela era um dos clientes que utilizam os produtos na sua AP fase prematura. Depois que o projeto comeou, a FoxMeyer assinou um contrato grande para fornecer para o University Health S ystem Consortium (UHC), um volume de negcios em torno de $1 bilho ao ano. Este contrato exacerbou a necessidade para um volume sem precedentes de transaes no R/ 3. Embora, antes do contrato, os testes indicavam que o R/ 3, rodando em uma plataforma HP9000, teria capacidade de lidar com altos volumes de transaes, em 1994 o R/ 3 conseguia processar somente 10.000 ordens de clientes por noite, comparado aos 420,000 do sistema original do mainframe da FoxMeyer (Jesitus 1997). Em terceiro lugar, a execuo do projeto era um problema devido falta de pessoal com conhecimento e habilidade. A FoxMeyer no tinha as competncias internas necessrias e estava confiando Andersen C onsulting a implementao do R/ 3 e a integrao do ERP com um sistema de automatizao de armazns da Pinnacle. Embora durante a execuo do projeto houvesse cerca de 50 consultores na FoxMeyer, muitos deles eram inexperientes e o turnover era elevado (Computergram International 1998). Finalmente, no quadrante do ambiente da estrutura do risco, pode ser encontrado o excesso de problemas que a gerncia do projeto tinha pouco ou nenhum controle (Keil, Cule, Lyytinenand S chmidt 1998). Embora a FoxMeyer tivesse percebido que o projeto estava com problemas, sua dependncia dos consultores e do fornecedor impedia que ela conseguisse enxergar como poderia retomar o controle do mesmo. Uma vez que a FoxMeyer estava competindo em termos de preo, ela necessitava de um volume elevado de transaes para ser rentvel. Contudo, com o contrato do UHC o foco do projeto mudou dramticamente, contribuindo para o aumento dos custos do mesmo (eventualmente, um estouro de $100 milhes), baixando as margens j estreitas da FoxMeyer e corroendo sua rentabilidade. Dado o elevado nvel de risco, por que a FoxMeyer iniciou o projeto? Alm disso, por que deixaram o projeto ganhar propores de modo a contribuir com a bancarrota da FoxMeyer? Escalabilidade do projeto Os sistemas do mainframe da FoxMeyer estavam tornando-se inadequados para seu crescente volume de negcios. Alm disso, seu sistema Unisys estava defasado e necessitava ser substitudo. O projeto Delta foi previsto como uma soluo cliente/ servidor R/ 3 integrada com armazns automatizados, com a finalidade de acomodar o crescimento futuro da companhia. Um modelo de fatores que promovem a escalabilidade de um projeto sugere que: (1) fatores de projeto, (2) fatores psicolgicos, (3) fatores sociais e (4) fatores organizacionais contriburam ao mesmo tempo para a continuao do projeto apesar de toda a sinalizao negativa disponvel (Keil 1995). A implementao parecia estar com problemas desde seu comeo. Apesar dos avisos da Woltz Consulting, durante os estgios iniciais do projeto, de que um planejamento para que a execuo inteira estivesse terminada em 18 meses era totalmente irreal, o projeto Delta da FoxMeyer foi adiante (Jesitus 1997). Fatores do projeto O aumento das dimenses do projeto mais provvel quando h uma expectativa que a continuao dos investimentos poderia produzir um maior retorno. A FoxMeyer esperava que com o projeto Delta conseguisse economizar at $40 milhes por ano. A Andersen Consulting e a S AP tambm estavam motivados a continuar o projeto. De acordo com a FoxMeyer, a Andersen Gerenciamento de projetos
56 utilizou estagirios (Caldwell 1998) e usou o projeto Delta como um campo de treinamentos para os consultores novatos " (Computergram International 1998). S imilarmente, a FoxMeyer reivindicou que a S a tratou como a sua prpria cobaia de pesquisa e desenvolvimento " AP (Financial Times 1998). Alm disso, os recuos do projeto pareciam ser temporrios. Por exemplo, existiam algumas mtricas que mostravam que os sistemas poderiam executar o volume de transaes requerido pela FoxMeyer. Fatores psicolgicos A Andersen e a S tinham um histrico de sucesso que os incentivava a continuar o projeto. A AP Andersen afirmou ns entregamos um sistema eficaz, da mesma forma que fazemos para outros milhares de clientes (Computergram International 1998). O CIO da FoxMeyer, Robert Brown, tinha havia colocado um elevado grau de responsabilidade pessoal no projeto ao afirmar que, ns estamos apostando nossa companhia neste projeto. (Cafasso 1994). Alm disso, ele expressou toda sua carga emocional no projeto quando enfatizou a respeito de que um sistema integrado computadorizado de $65 milhes, construdo em S R/ 3 melhoraria de forma radical as AP operaes crticas da companhia. Entretanto, a FoxMeyer colocou uma carga maior do que ela poderia suportar, uma vez que faltavam usurios disponveis na equipe de funcionrios com a sofisticao necessria para assegurar uma instalao rpida. Tambm, a deciso de utilizar dois fornecedores diferentes para dois dos sistemas mais importantes do negcio da companhia era um erro em se tratando de processamento de informaes (Keil 1995). Isto adicionou ainda mais complexidade a uma situao j desafiadora (Jesitus 1997). Fatores sociais provvel que a Andersen Consulting e a S tivessem necessidade de justificar externamente o AP projeto Delta. Provavelmente no consideraram reduzir a escala do projeto, uma vez que o abandono do mesmo no seria uma boa publicidade. Alm disso, suas normas para consistncia (Keil 1995) eram tais que a perseverana em lidar com problemas de projetos lhes traria a compensao necessria. Fatores Organizacionais Tanto o CEO quanto o CIO da FoxMeyer eram patrocinadores fortes do projeto. Entretanto em fevereiro de 1996, Thomas Anderson, o presidente e CEO da FoxMeyer Health (e executivo responsvel pelos projetos de integrao da companhia e automatizao dos armazns) foi solicitado a renunciar devido ao atraso do novo armazm e s falhas em concretizar as economias previstas pelo sistema S Uma mudana na gerncia frequentemente motivo para a reduo AP. da escala do projeto (Montealegre e Keil 1998). Mas j era muito tarde para a FoxMeyer. Os relatrios pareciam indicar que a FoxMeyer afrouxou os controles gerenciais, demonstrado pelo fato que a gerncia no controlou o escopo do projeto Delta. Por exemplo, originalmente, a FoxMeyer esperava que a Andersen projetasse um sistema que poderia despachar em um nmero X de horas. Embora a Andersen tivesse projetado um sistema capaz de fazer isto, posteriormente a FoxMeyer queria estar pronta para despachar entre um tero e a metade deste tempo (Jesitus 1997). Tambm, com o contrato do UHC, a capacidade de processamento do sistema S teve que ser aumentada substancialmente. Alm disso, a FoxMeyer no teve polticas AP e procedimentos adequados de gerenciamento de mudanas. Por exemplo, seus problemas trabalhistas explodiram quando os trabalhadores comearam a deixar e trabalho em massa nos seus trs armazns de Ohio, que foram programados para serem substitudos pelo Centro Gerenciamento de projetos
57 Automatizado de Controle de Washington. Por causa de um problema de debilidade moral entre os trabalhadores que estavam saindo, muitas das mercadorias foram despejadas nos caminhes e chegaram ao Centro de Controle de Washington com suas embalagens danificadas ou abertas ou de outra maneira inadequadas para serem utilizadas como um produto novo, [tendo por resultado] uma reduo enorme de inventrio (Jesitus 1997). Questes para discusso - Quais as principais falhas no gerenciamento do projeto Delta III? - Neste caso temos o exemplo dos riscos envolvidos na adoo de novas tecnologias, como a FoxMeyer poderia minimizar estes riscos? - Quais seriam as melhores estratgias para cada tipo de risco analisado pela estrutura adotada (patrocnio do cliente; escopo e requisitos; execuo e ambiente)? - Como poderiam ser atacados os fatores que levaram ao aumento da escala do projeto? Referncias Cafasso, R. "Success strains SAP support", Computerworld, 28(36), September 5, 1994. Caldwell B. "Andersen Sued On R/3", InformationWeek, July 6, 1998. Computergram International "FoxMeyer Plus Two Sue Andersen for SAP Snafus", Computergram International, July 20, 1998. Financial Times "SAP in $500m US lawsuit", Financial Times, Surveys, September 2, 1998, 2. Jesitus, J. "Broken Promises?; FoxMeyer 's Project was a Disaster. Was the Company Too Aggressive or was it Misled?", Industry Week, November 3, 1997, 31-37. Keil, M., Cule, P.E., Lyytinen, K., and S chmidt, R.C. "A framework for identifying software project risks", Communications of the ACM, 41(11), November 1998, 76-83. Keil, M. "Pulling the plug: S oftware project management and the problem of project escalation", MIS Quarterly, 19(4), December 1995, 421-447. Markus, M. L. and Benjamin, R. I. "The magic bullet theory in IT-enabled transformation", S loan Management Review, 38(2), Winter 1997a, 55-68. Markus, M. L. and Benjamin, R. I. " Are you gambling on a magic bullet?", Computerworld, 31(42), October 20 1997b, C1-C11. Montealegre, R. and Keil, M. "Denver International Airport's Automated Baggage Handling system: A Case Study of De-escalation of Commitment", Academy of Management Proceedings, August 1998. Stein T. "SAP Sued Over R/3", InformationWeek, August 31, 1998.
58
3.3 Estudo de Caso - Globalstar: conectando todo mundo, de todo lugar

Um anncio surpreendente No dia 25 de agosto de 1999, os leitores do Wall S treet Journal e de outros jornais importantes ficaram surpresos ao se deparar com um anncio que trazia uma carta de John Richardson, o novo diretor-presidente da Iridium. A Iridium era um sistema de telefonia global, baseado em satlite e sem fio que a empresa tinha lanado h apenas nove meses. Na carta, Richardson dizia: Pioneiros, entretanto, deparam-se com desafios nicos, e cometemos alguns erros no lanamento de nosso servio. Reconhecemos nossos erros e estamos trabalhando diligentemente para corrigilos. Nossa principal meta oferecer um servio de classe mundial para nossos clientes. Para alcanar nossos objetivos, devemos colocar nossa situao financeira em ordem. A Iridium LLC recentemente entrou com pedido de reorganizao, Captulo 11, num esforo para concluir uma reestruturao financeira em um processo ordenado e supervisionado (...) Quero deixar claro para nossos clientes, investidores e parceiros do mundo todo que a Iridium continuar a oferecer seu servio de telecomunicaes global pioneiro e de alta qualidade sem interrupo. Ainda estamos na ativa, normalmente. Saindo de rbita Os desenvolvedores de telecomunicaes por muito tempo sonharam com uma rede de satlites em rbita ao redor da Terra que permitisse que uma pessoa fizesse ligaes telefnicas de qualquer lugar do mundo. A Iridium e seus financiadores como a Motorola e a Kyocera, uma fabricante de componentes japonesa demoraram mais de 12 anos e investiram mais de cinco bilhes de dlares para fazer desse sonho uma realidade. Como uma empresa to festejada pde falir to drasticamente, de maneira to rpida? Os engenheiros da Iridium desenvolveram um sistema que contava com 66 satlites para unir uma rede de telefonia celular em terra que combinava 200 servios oferecidos em 90 pases. A empresa organizou seus membros em 15 gateways (pontos de contato) regionais, que eram responsveis por promover os servios da Iridium nessas reas. Os gateways eram os sistemas de transferncia em terra que recebiam e direcionavam as chamadas de e para os satlites. Os financiadores da Iridium achavam que havia um grande mercado potencial para esse servio de telefonia. Na verdade, um estudo da Merrill Lynch previu que em 2007 32 milhes de assinantes em todo o mundo estariam pagando quase 32 bilhes de dlares por ano pelo servio de telefonia via satlite. O estudo apontou que 65 por cento dos lares no mundo no tinham telefone. Mostrou tambm que o servio de telefonia celular no tinha penetrado em muitos pases desenvolvidos e que mesmo nos Estados Unidos e na Europa grandes reas no tinham cobertura para celular. A agncia de propaganda Ammirati Puris Lintas (APL) trabalhou com a Iridium no desenvolvimento da estratgia de marketing. A APL deslocou oito gerentes de seus escritrios em 77 pases para trabalhar com os gerentes da Iridium. A equipe da APL apresentou uma anlise de 600 viajantes globais, pessoas importantes que percorriam o mundo fazendo negcios. A pesquisa da APL apontou que essas pessoas se preocupavam em estar fora de contato quando viajavam para lugares distantes. Temiam perder os acontecimentos na empresa ou de estar fora de contato e, Gerenciamento de projetos
59 conseqentemente, fora do controle. Eles se preocupavam tambm em negligenciar a famlia. Essas pessoas tinham altos cargos e no mnimo 35 anos, ou eram pessoas que tinham ocupaes diferentes, como exploradores de petrleo ou produtores de filmes. A Iridium j tinha o produto que acalmava esses medos dos executivos e ia ao encontro de seu desejo por status. Entretanto, o nico modelo de telefone que a empresa desenvolveu se parecia com um tijolo e tinha uma antena parecida com uma bisnaga. Junto com o telefone, o executivo teria que carregar uma maleta recheada de uma desconcertante quantidade de acessrios e adaptadores. Alm disso, para utilizar o telefone, o executivo teria que ter certeza de que a antena estava voltada para a direo certa, em direo ao satlite, e de que no havia nada bloqueando o sinal. Assim, o cliente no poderia utilizar o telefone dentro de prdios ou carros. A Iridium oferecia um servio de roaming, de modo que os clientes tinham que acessar as redes de celular ao redor do mundo e pagar pelo servio. Os clientes tinham apenas um nmero de telefone para todos esses servios ao redor do mundo e recebiam apenas uma conta. A Iridium estava preocupada em rever seu investimento. Alm disso, seguiu uma poltica de determinao de preos para o mercado de elite, cobrando mais de trs mil dlares por um aparelho e mais de sete dlares por minuto de ligao. A determinao de preos tambm ajudou a posicionar o telefone como um smbolo de status e atraiu pessoas dispostas a pagar um alto preo para ser a primeira a ter o novo telefone. S ob a estrutura organizacional da Iridium, as organizaes regionais de gateway eram responsveis por desenvolver a distribuio e planos de marketing para suas reas. Entretanto, a data de lanamento planejada, setembro de 1998, aproximava-se e poucas tinham feito isso. Faltava, a alguns dos parceiros, experincia com telecomunicaes. Muitos gerentes achavam que era essencial posicionar a Iridium como uma marca global o mais rpido possvel. Assim, para promover o projeto, a Iridium alocou 125 milhes de dlares para uma campanha que foi lanada em 50 pases. Anncios de duas pginas em grandes revistas diziam que os executivos bem-sucedidos precisavam estar conectados, em contato e no controle. Os anncios, os comerciais e as malas diretas bajulavam e assustavam os executivos. Um anncio de jornal dizia: S voc quer ser o dono do mundo, precisar de um telefone que possa e acompanh-lo. A APL variou suas promoes de acordo com a regio (em cerca de 20 idiomas), mas o tema universal era o entusiasmo e a ansiedade com o sucesso global. A propaganda comeou trs meses antes do lanamento, para provocar desejo pelo produto. Em poucas semanas, mais de um milho de clientes enviou perguntas sobre a Iridium. A empresa transmitiu essas perguntas para os parceiros regionais, mas a maioria no estava preparada para respond-las. Alm disso, quando a empresa finalmente lanou seus servios, em novembro de 1998, os telefones no estavam funcionando 100 por cento. Em agosto de 1999, a empresa admitiu que tinha somente 20 mil assinantes, um nmero bem inferior ao que tinha sido previsto e aos 500 mil clientes de que ela precisava para cobrir seu um bilho de dlares em custos operacionais anuais e para pagar a dvida junto aos bancos. A empresa entrou em estado de emergncia marchava para a falncia e buscava a reorganizao. A Globalstar pode se dar bem? Uma das razes da impetuosidade da Iridium foi saber que os concorrentes estavam logo atrs. A Globalstar, a ICO Global Communications, a Teledesic e a Ellipso estavam preparadas para
60 construir sistemas de telefonia via satlite. A ICO, entretanto, seguiu a Iridium em direo falncia. A Globalstar, situada em S Jose, na Califrnia, tinha como objetivo ser lanada em 1999 e an planejava investir 3,8 bilhes de dlares em um sistema de 48 satlites. Os primeiros investidores da Globalstar foram a Lora Space and Communications e a Qualcomm. A equipe da Globalstar est tentando no incorrer nos mesmos erros da Iridium. Enquanto a Iridium mirava os importantes executivos que estavam sempre viajando, a Globalstar procura oferecer servios domsticos em pases desenvolvidos. S egundo Bernard S chwartz, diretorpresidente da Globalstar e da Loral, os principais clientes so as pessoas que no possuem telefone e que vivem em reas onde no h servio de celular. Essas pessoas esto integradas, por meio de seus negcios ou de outros relacionamentos, com os centros de negcios mais populosos. Apesar de os executivos poderem utilizar os servios da Globalstar, S chwartz quer ter como alvo pessoas que vivem no mundo semimoderno, mas que sentem falta de comunicao instantnea. S chwartz acredita que Mxico, Canad, Brasil, ndia, China, Indonsia e Rssia constituem mercados-chave. Outro executivo da Globalstar sugere que os mercados verticais, como as empresas de recursos naturais, as plataformas de explorao de petrleo e as empreiteiras constituem mercados importantes. A Globalstar projetou telefones que permitem aos usurios escolher entre o servio por satlite e o da telefonia celular, oferecendo a eles total cobertura a um preo mais baixo. O telefone possui acessrios que permitem que seja utilizado em carros ou em navios. Alm da comunicao vocal, a Globalstar oferece servios de roaming, posicionamento, fax e transmisso de dados. A empresa fixou o preo de seu telefone em cerca de 1 250 dlares, com os servios custando aproximadamente 1,25 dlar por minuto. Apesar de esses preos ainda estarem muito altos os celulares da Nokia saem por 200 dlares e os servios custam dez cents por minuto , a Globalstar tem como alvo os clientes que no tm essa opo. Para construir sua infra-estrutura de servios, a Globalstar vende acesso a seu sistema para empresas de servio de telefonia locais e regionais do mundo inteiro. Essas empresas se associam a outras empresas locais para oferecer o sistema de telefonia que melhor se encaixa s necessidades dos clientes locais. Complementando as redes de telefonia em terra, em vez de competir com elas, a Globalstar acredita que encontrar novos mercados e levar o servio de telefonia para novas reas. A empresa calcula que precisa de apenas 200 mil assinantes para atingir o ponto de equilbrio. Entretanto, conseguir esses 200 mil clientes no fcil. S chwartz e outros administradores deparam-se com inmeros desafios. Colocar 48 satlites em rbita no tarefa pequena. Em setembro de 1998, um foguete feito na Ucrnia partiu do complexo de lanamento Baikonur, no Cazaquisto, com 12 dos satlites da Globalstar. O foguete caiu e pegou fogo, destruindo cem milhes de dlares em satlites. O acidente atrasou o lanamento da Globalstar, uma vez que eram necessrios 32 satlites em rbita para a empresa iniciar seus servios. No dia 11 de outubro de 1999, a empresa anunciou o lanamento oficial de seus servios, que ela planejava operar regionalmente em reas do mundo atendidas por seus nove gateways operacionais. Para completar, em 22 de novembro de 1999, a Globalstar anunciou que tinha colocado quatro satlites adicionais, atingindo um total de 48 em rbita. Com isso, ela poderia iniciar seu servio comercial completo no incio de 2000, aps quatro satlites de reserva adicionais estarem no lugar. Gerenciamento de projetos
61 Mesmo com os satlites em rbita, a Globalstar ainda tem que entrar em acordo com mais de cem agncias governamentais, lidar com as crises monetrias e concluir a construo de seus 36 gateways. Talvez, entretanto, a tarefa mais difcil, depois da falncia da Iridium, seja persuadir os investidores a empatar bilhes de dlares para apoiar o empreendimento. Isso que chamada de longa distncia! O fracasso da Iridium levou os analistas a questionar se realmente existe mercado para servios de telefonia via satlite. melhor a Globalstar responder a esses questionamentos provando que as pessoas de todos os lugares querem estar conectadas.
3.4 Ouro Perdido

Phydia de Athayde Fonte: Carta Capital no. 433 Fev. 2007 Com o custo aumentado em dez vezes, e sem trazer melhorias estruturais para a cidade, os Jogos do Rio so uma metfora do Brasil que no sabe crescer Faltam menos de 150 dias para o incio dos XV Jogos Pan-Americanos, dia 13 de julho, no Rio de Janeiro. Tempo curto se comparado ao que a cidade teve para se preparar. Tambm curto para obras que j no podem mais atrasar, como vinha acontecendo, sob o risco de simplesmente no ficarem prontas. Mas o tempo mais do que suficiente para que todos os envolvidos na organizao passem a repetir, quando o assunto for o Pan-Americano, estamos na ltima volta do ponteiro, a reta final. Agora vai. Agora que o oramento cresceu mais de dez vezes e que o medo de um vexame internacional justifica tudo, agora vai. A menos de cinco meses dos jogos, as disputas polticas amainaram, o dinheiro apareceu e algumas obras esto perto de ficar prontas. hora de garantir ao Pas que tudo vai bem, que o melhor momento j vivido pelo esporte nacional, que o Brasil est a um passo de se tornar sede de Olimpadas, da Copa do Mundo de 2014, e assim por diante. Por trs de tanto otimismo repousam, porm, fatos e atitudes capazes de arruinar as pretenses brasileiras de sediar grandes eventos esportivos internacionais. Ou, ainda, fazer com que aconteam sem que tragam um mnimo de benefcios ao Pas. A maneira como o esporte administrado, o descaso com a exploso nos custos e a displicncia quanto ao planejamento urbano so alguns desses pontos. O Comit Olmpico Brasileiro (COB) presidido por Carlos Arthur Nuzman desde 1995. Formado em Direito, Nuzman foi jogador da S eleo Brasileira de Vlei de 1962 a 1968. Pouco depois, em 1975, elegeu-se presidente da Confederao Brasileira de Voleibol e l permaneceu durante 20 anos. frente do vlei, Nuzman aproximou o marketing do esporte e, com esse capital, pavimentou o caminho para as vitrias que a modalidade conquistou desde ento. Mrito inequvoco. O mesmo esprito de empreendedor aliado ao marketing levou Nuzman presidncia do COB, onde est h mais de 12 anos. Ao todo, so 32 anos como dirigente esportivo. Nas ltimas eleies para a presidncia da entidade, em 2004, nem sequer havia concorrentes. Nuzman reelegeu-se Gerenciamento de projetos
62 com facilidade, tal como dever fazer em 2008. criao dele, por sinal, uma clusula que exige que qualquer candidato presidncia do COB esteja h pelo menos cinco anos na entidade. Na prtica, dois mandatos. Esse modelo que facilita a perpetuao de dirigentes criticado por atletas como Oscar Schmidt, o maior craque que o basquete brasileiro j teve: Os presidentes entram, no tm salrio e no querem mais sair. No nosso sistema votam clubes, federaes e confederaes, s quem no vota a parte mais importante do esporte, o atleta. O atleta no manda nada, no respeitado e fazem o que querem dele. O distanciamento entre a realidade do atleta e a realidade dos dirigentes tambm pode ser visto sob outro aspecto. Das 33 confederaes de esportes que estaro no Pan, a maioria (42%) tem sede no Rio de Janeiro. Em S Paulo esto 27% dessas entidades, embora o estado abrigue 45% o dos atletas que treinam para o Pan. Muitos, inclusive, so esportistas que tiveram de abandonar o Rio em busca de patrocnio e apoio financeiro, itens cada vez mais escassos nos clubes cariocas. Mesmo perdendo atletas, o fato de o Rio concentrar as sedes de confederaes ajuda a explicar sua vitria nas votaes para escolher a candidata ao Pan-2007. S Paulo, que foi sede do Pano Americano em 1963, concorreu e foi derrotada. A capital fluminense , por extenso, a fortaleza poltica de Nuzman. Atletas de esportes olmpicos referem-se ao presidente do COB como Deus, tamanho o seu poder. Uma das raras excees a esse temor misturado com adulao est em Magic Paula, ou Maria Paula Gonalves da S ilva, uma das maiores jogadoras de basquete do Pas. Em 2003, ela pediu exonerao da S ecretaria Nacional de Alto Rendimento, no Ministrio do Esporte, por no concordar com a relao promscua entre Nuzman e o ento ministro Agnelo Queiroz. Os custos da estadia de Paula e Queiroz na Repblica Dominicana, durante o Pan-Americano de 2003, foram pagos pelo COB. Apenas uma das muitas cortesias da entidade a quem lhe interessa. Alm de no concordar com esse comportamento, Paula critica a falta de planejamento do ministrio e o abandono das categorias de base no esporte. Ela falou a CartaCapital sobre o que significa um Pan no Brasil: O problema do esporte brasileiro mais embaixo. No um Pan-Americano aqui que vai solucion-lo. Alm do mais, esse um gasto absurdo. Com muito menos dinheiro daria para estruturar o esporte no Pas. O Pan importante para dar visibilidade ao esporte e seria bom se tivssemos base, se tivssemos estrutura para os atletas se manterem e trabalharem. Fico preocupada com os atletas depois que tudo acabar e eles voltarem a viver na corda bamba. Paula diz que um dos fatores que perpetuam as mazelas do esporte focar os patrocnios apenas nos atletas de ponta, esquecendo da base: Na formao de atletas mesmo, pouca gente est interessada. S interessa quem j est l em cima. No existe poltica esportiva para o Pas, ento cada um faz sua maneira. Quando o governo cria uma lei de incentivo que no exige contrapartida social, os beneficiados sero os mesmos de sempre. Paula refere-se Lei de Incentivo ao Esporte, sancionada pelo presidente Lula em 29 de dezembro de 2006. Formulada nos moldes da Lei Rouanet, a lei prev a renncia de parte do Imposto de Renda para ser investida no esporte. A exemplo do que j acontece com a Lei Rouanet, teme-se Gerenciamento de projetos
63 que os benefcios fiscais acabem indo para projetos que ofeream grande visibilidade e beneficiem, sobretudo, quem goze de timo trnsito nas ante-salas de marketing. Para 2007, estima-se que 300 milhes de reais sejam destinados a projetos ligados ao esporte em razo da nova lei. No Brasil, desde 2001, a Lei Agnelo-Piva destina 2% da arrecadao das loterias para o esporte olmpico. O COB recebe esse dinheiro e trata de repass-lo para as confederaes e para si mesmo. No ciclo olmpico para os Jogos de Atenas, a entidade recebeu 158 milhes de reais. Boa parte desse montante usada para custear viagens internacionais dos atletas, feitas sempre atravs da agncia de viagens oficial do COB, a Tamoyo Internacional. A verba tambm ajuda a manter as instalaes do COB, na Barra da Tijuca, e do Comit Organizador dos Jogos Pan-Americanos do Rio de Janeiro (CO-Rio), no mesmo prdio. No CO-Rio trabalham mais de dez ex-atletas olmpicos. Paula Andrade e Paula Hernandez, do vlei. Agberto Guimares e Rafael Gonalves, do atletismo. Christiane Paquelet e Ricardo Prado, da natao. Ricardo Trade, do handebol. S ebstian Pereira, do jud. S oraya Carvalho, da ginstica, e Ceclia Marques, do plo aqutico, entre outros, como o ex-atleta do remo e vice-presidente do CO-Rio, Andr Richer. No essencialmente condenvel que ex-atletas trabalhem nos comits olmpico e panamericano. Grave quando integrantes do COB trabalham em empresas que prestam servios ao prprio COB. O chefe da delegao brasileira nas Olimpadas de Atenas e Pequim, Marcus Vincius Freire, ex-atleta do vlei, at o ano passado era diretor de marketing da seguradora Aon Brasil. Por anos a Aon, de Freire, serviu ao COB, de Nuzman. A delegao brasileira nas Olimpadas de Atenas usou uniformes assinados pela estilista Mnica Conceio, que cunhada de Nuzman. Aos amigos, tudo. H mais relatos de condutas pouco louvveis, para no dizer escandalosas, como o assdio a uma empresa do setor de alimentao. Um emissrio do COB contatou-a oferecendo intermediao para o processo de licitao pblica. A empresa recusou a oferta. E declinou da licitao. Outro relato trata de um fornecedor de painis eletrnicos convidado a oferecer seus produtos por um valor acima do preo normal. A empresa recusou o convite. Em seguida, surge uma segunda empresa, disposta a comprar os equipamentos da primeira e a revend-los pelo preo sugerido. Crticos do COB dizem que o Pan-Americano tornou-se um balco de negcios. No se depender das palavras do secretrio-geral do CO-Rio, Carlos Roberto Osrio, para quem nenhuma instituio no Brasil to controlada quanto o CO-Rio (entrevista abaixo). Osrio explica que toda a movimentao financeira para os Jogos Pan-Americanos sujeita aprovao dos Tribunais de Contas do Municpio, do Estado e da Unio, alm de cumprir procedimentos administrativos aprovados pelo nosso conselho-executivo baseados na legislao em vigor. Mesmo assim, s no d para ignorar que os Jogos Pan-Americanos no Brasil custaro dez vezes mais que o programado. H muitas verses para essa exploso de gastos. Nuzman devolve a pergunta: Que pas cumpriu um oramento inicial? verdade que faz parte da histria de Olimpadas estourar oramentos (histrico dos Jogos nesta pgina). S no se tem notcia de um oramento que tenha decuplicado. Ainda mais de um Pan-Americano.
64 Antes de seguir, convm lembrar que Jogos Pan-Americanos so tradicionalmente pouco significantes no cenrio mundial. Em toda a histria das 14 edies do Pan, somente dez recordes mundiais foram quebrados. Nas Olimpadas de Atenas, para ter uma idia, foram batidas 21 marcas mundiais. Juca Kfouri observou em sua coluna, na Folha de S.Paulo, que desde 1979 no se bate um recorde mundial em Pan-Americanos. Alm do mais, a gastana desenfreada que jornais vm denunciando criminosa, denuncia Kfouri, e identifica a chantagem que era prevista diante do fato consumado e da necessidade de salvar o Pas. Faz cinco anos que o Rio de Janeiro foi escolhido para ser a sede do Pan-Americano de 2007. Agora, a pouco mais de cinco meses do incio dos Jogos, o temor de um fracasso justifica gastos emergenciais. O discurso oficial repete que tudo est sob controle, mas h apreenso no ar. Na tera-feira 6, o presidente Lula esteve no Rio de Janeiro para a primeira inaugurao de algo relacionado ao Pan. O Centro de Operaes Tecnolgicas compilar todos os dados referentes aos Jogos e custou 112 milhes de reais aos cofres do governo federal. Ao lado do ministro do Esporte, Orlando S ilva, do governador do Rio, S rgio Cabral, e de representantes do Comit Olmpico e do municpio, Lula frisou querer um acompanhamento milimtrico das obras de agora at julho. Repetindo a tese do COB, voltou a ligar o sucesso do Pan s chances de o Brasil ser sede das Olimpadas de 2016: A responsabilidade dos entes federativos decisiva para a imagem que o Brasil quiser mostrar. Os Jogos Pan-Americanos sero uma espcie de vestibular para a nossa competncia em organizar eventos esportivos. O Brasil no medir esforos para que os Jogos Pan-Americanos sejam os melhores j realizados nesta Amrica. mesmo bom serem os melhores Jogos Pan-Americanos da Amrica, j que o governo federal investiu, sozinho, 1,5 bilho de reais. Dez vezes alm do previsto inicialmente, vale relembrar. O que faz um oramento decuplicar? Talvez ambio. Ou pretenso. O Brasil candidatou-se para receber Jogos Pan-Americanos. Assim que foi escolhido, passou-se a tratar os Jogos como uma pr-candidatura olmpica. Essa tese, defendida pelo COB, foi bem costurada e defendida nas trs esferas de governo, como se ver. O secretrio-executivo do Comit Gestor das Aes Federais para o Pan-Americano, Ricardo Leyser, falou a CartaCapital: H 30 anos no se fazem investimentos de porte em equipamentos esportivos no Brasil. S o e investimento feito, ele no pode visar s um evento. importante que capacite o Pas para uma Olimpada, para um Mundial. O Brasil candidato a sede dos Jogos Mundiais Militares de 2011, por exemplo. mais caro, mas no valeria a pena no fazer. Leyser, no entanto, critica a forma como o oramento foi apresentado inicialmente pelo COB: Originalmente, essa diviso de recursos foi mal planejada. No foi realista. A conta do governo federal multiplicou por 10, o que significativo. Alguns itens no estavam previstos, como os investimentos em segurana. Estamos comprando 27 aeronaves, algumas ficaro no Rio, outras sero distribudas. Mais de 1,1 mil viaturas ficaro no Rio, isso legado. O investimento federal em segurana, estimado em 385 milhes de reais, visa dar tranqilidade aos cariocas, aos turistas e aos atletas. Convm levar em conta a questo das milcias que proliferam no Rio. Essas organizaes vm tomando as favelas, especialmente no entorno das vias de acesso, como a Linha Amarela, ou dos complexos esportivos. A chance de estourarem revides violentos, inclusive durante os Jogos, no baixa. Gerenciamento de projetos
65 Ruy Csar Miranda Reis, secretrio especial do municpio para o Pan, evitou o tema segurana. Preferiu falar de oramento: S fosse apenas para o Pan-Americano, os Jogos custariam 300 milhes de reais e a prefeitura e entraria com 172 milhes. Hoje, nossos custos passam de 1 bilho de reais. Os Jogos tinham um valor, mas, com a candidatura para a Olimpada, isso cresceu. Esse centro tecnolgico, por exemplo, seria importante para o Pan-Americano, mas no fundamental. um salto de pretenso e de qualidade. No governo do estado, entra S rgio Cabral e saem os Garotinho. O novo secretrio estadual de Esportes e Turismo, Eduardo Paes, falou a CartaCapital da situao das obras: Encontramos um dbito monstruoso, obras quase paradas ou muito atrasadas, como as do Maracanzinho. S este ano, o governo estadual liberar 250 milhes de reais, a maior parte para obras no complexo do Maracan. um esforo enorme. Nem o esforo dos governos estadual, federal e municipal ser capaz de oferecer cidade algo alm dos locais de competio. A saber: o setor de transporte pblico seria, de acordo com o projeto de candidatura, o maior beneficiado com os Jogos. Previam-se novas linhas de metr (duas delas constavam no caderno de encargos da candidatura), a implantao de corredores de nibus e at de uma linha de barca martima que ligaria a Barra da Tijuca ao centro da cidade (quadro ao lado). Nada saiu do papel. As propostas mofam no plano diretor de transportes da cidade, publicado no Dirio Oficial do Municpio em maio de 2006. Alm de no haver melhora no transporte pblico, a cidade ainda ter de absorver os milhares de turistas e garantir que atletas e oficiais ligados ao Pan cheguem aos locais de competio a tempo. Como? Coube prefeitura o deslocamento da chamada Famlia-Pan (equipes e oficiais). A despeito dos congestionamentos que a cidade j enfrenta diariamente, o prefeito Cesar Maia no se alarma: preciso levar em conta que 70% dos eventos acontecero na Barra. E os deslocamentos para a zona sul, para Deodoro e para o Maracan sero feitos em corredores exclusivos durante a passagem pela Lagoa-Barra. A ligao Lagoa-Barra j uma das mais congestionadas da cidade. Ao pblico restar enfrentar engarrafamentos ou tentar o transporte pblico disponvel ou, ainda, as linhas circulares que esto para ser criadas. Ao redor dos locais de competio no ser permitido estacionar veculos particulares. O caos anunciado nas avenidas cariocas levou o ministro do Esporte, Orlando S ilva, a fazer a primeira crtica s oportunidades perdidas com o Pan. Em infra-estrutura poderamos ter algo a mais. S obretudo, para quem acalenta o sonho olmpico, precisaramos de um transporte melhor, pontuou. S ilva tambm lembrou que as mesmas deficincias no transporte contriburam para a derrota do Rio candidatura olmpica para 2008. A menos de cinco meses dos Jogos Pan-Americanos, visvel que a prioridade de investimentos foi para as instalaes esportivas, enquanto a cidade foi deixada em segundo plano. A candidatura tambm previa a despoluio da Baa de Guanabara, onde acontecero as competies de vela, e da Lagoa Rodrigo de Freitas, rea de remo e canoagem. No vo acontecer. Aos atletas da vela, restar deslizar sobre dejetos. tanto lixo que tenho medo de arrebentar Gerenciamento de projetos
66 uma prancha de 4 mil dlares, batendo numa geladeira, reclamou o velejador Bimba, depois de conhecer as condies da Baa de Guanabara. Perdida a oportunidade, sobram as explicaes. Leyser, do Comit Gestor das Aes Federais no Pan, alega: O Pan no tem uma agenda ambiental obrigatria. Isso so invenes. O que h de efetivo so os projetos de despoluio da baa, em andamento muito antes de o Rio ser candidato. E o governo federal fornecer 25 milhes de reais para construo de uma estao de tratamento de esgoto prxima Vila do Pan, que ajudar a despoluir as lagoas da Barra. Quanto ao transporte: Investir em transporte tambm no obrigao do Pan. No prometemos nada. uma promessa que algum fez a, mas tambm no obrigatrio para o Pan. claro que o ideal que tivesse havido um investimento maior em legado. J que o grosso dos investimentos foi para as instalaes esportivas, cabe discutir o que ser feito delas aps os Jogos. A obra mais cara do Pan-Americano a construo do Estdio Joo Havelange. Orado em 166 milhes de reais, j est em 360 milhes. Mas ningum sabe dizer o que ser feito dele depois dos Jogos. O Engenho, como chamado, responsabilidade da prefeitura. Ele ter instalaes para atletismo e tambm um campo de futebol. O destino disso tudo? Pergunte prefeitura, o que se diz. Cesar Maia ensaia uma resposta: Espero que um clube de futebol do Rio assuma a concesso na licitao. O mtodo ser a participao da prefeitura nas receitas diversas. Ruy Miranda, tambm da prefeitura, d detalhes: J conversamos com clubes da cidade, Flamengo e Botafogo. O Fluminense no se interessou muito. Vamos desenhar uma concesso para algum do mundo empresarial que entenda de esporte e que tenha interesse em gerenciar aquele complexo esportivo. A jogadora Paula tambm falou sobre o destino das instalaes feitas para o Pan. Porm, com preocupao: O que ser delas? Haver programas de formao de atletas ou apenas eventos pontuais, para trazer dinheiro? Eu no sou do oba-oba. No dependo de falar bem de um ou de outro. Vejo uma canaleta de dinheiro pblico escoando, e isso precisa de uma boa justificativa. H muitas outras formas de dar visibilidade ao Pas. As obras na Marina da Glria, por sua vez, ficaro marcadas como as mais problemticas na organizao desses Jogos. O projeto inicial previa mudanas drsticas na marina, tombada pelo patrimnio histrico, para torn-la capaz de abrigar as embarcaes para a competio de vela. O assunto arrastou-se em uma queda-de-brao at parar na Justia. Por pouco, a vela, um dos esportes em que o Brasil destaque internacional, no excluda do Pan. Depois de meses, enfim, chegou-se a um acordo que prev instalaes provisrias. Modestas e mais realistas. A resoluo do impasse na Marina da Glria talvez seja o melhor exemplo de um desfecho razovel nesses Jogos Pan-Americanos. A seu lado, outras duas obras tambm podem servir como analogias de um Brasil que quer ser grande, mas raramente acerta o caminho. O carssimo e sem Gerenciamento de projetos
67 destino Engenho, de um lado, e a abandonada e poluda Baa de Guanabara, de outro. Tristes trpicos. Uma questo de estratgia Carlos Roberto Osrio, do CO-Rio, d os detalhes finais do Pan O secretro-geral do Comit Organizador dos Jogos Pan-Americanos do Rio, Carlos Roberto Osrio, forma, ao lado de Carlos Arthur Nuzman, a dupla de ataque do Pan. Ele falou com exclusividade a CartaCapital. CartaCapital: A menos de 150 dias dos J ogos ainda no se definiu que empresa fornecer os ingressos. Quando a questo ser resolvida? Quando os ingressos estaro venda? Carlos Roberto Osrio: Ainda no temos a deciso. Durante o processo de concorrncia, apenas uma empresa apresentou a proposta fora dos padres aprovados pelo conselho executivo. Cancelamos e abrimos outro processo de licitao com parmetros revisados. A previso que o novo processo seja concludo em fevereiro e que no incio de maro faamos o anncio pblico de toda a operao. As vendas iniciam em maro. Teremos categorias diferenciadas de preo e ingressos populares na maioria dos eventos. No do nosso interesse que os Jogos sejam elitistas. CC: Com um preo mdio estimado em 30 reais, haver uma cota de ingressos gratuitos? CRO: S estamos chamando de ingressos sociais. Falta definir a quantidade, em que provas im, estaro e como sero distribudos. CC: A cidade receber milhares de pessoas e no tem estrutura para absorver esse volume extra no sistema de transporte. Como amenizar o caos? CRO: Nos Jogos Pan-Americanos no h exigncia de executar projetos de infra-estrutura na rea de transportes. Esse compromisso acontece em candidaturas olmpicas. Alm de algumas coisas tpicas, esses investimentos no puderam ser feitos. A prefeitura responsvel pelo manejo do transporte durante os Jogos. H um cuidado muito grande na tomada de decises na questo do transporte, que crtica em qualquer megaevento. No diria que teremos um problema terrvel. CC: O Rio foi escolhido apenas para ser sede do Pan. No entanto, as obras foram baseadas na idia de pleitear J ogos Olmpicos. Quem custear a manuteno dessas instalaes e como garantir que daqui a oito anos elas no estaro defasadas? CRO: A responsabilidade de manuteno de cada equipamento do rgo governamental responsvel por ele, que pode conced-lo iniciativa privada. Essa foi a estratgia montada. CC: As empresas que prestam servio ao COB passam por licitao? CRO: A Lei Piva no impe nada ao Comit Olmpico Brasileiro. Os recursos so repassados ao COB, e ns temos um procedimento para a utilizao deles. No uma licitao pblica. S omos uma entidade privada, mas recebemos recursos pblicos e temos de prestar contas. Todos os procedimentos administrativos foram aprovados pelo nosso conselho executivo, baseados na legislao em vigor. Prestamos contas aos Tribunais de Contas do Municpio, do Estado e da Unio, alm da Controladoria-Geral do Municpio e da Unio. Muito francamente, nenhuma instituio no Brasil to controlada quanto o CO-Rio. CC: Qual ser o destino do Engenho? CRO: Responsabilidade da prefeitura da cidade. Gerenciamento de projetos
68 CC: Todos repetem isso, mas o que efetivamente se pode dizer a respeito? CRO: O projeto do estdio Joo Havelange de um nvel espetacular. Em termos esportivos, nenhum estdio do mundo mais moderno. Em minha opinio tem um futuro bastante interessante. Giro olmpico Receber Jogos internacionais pode ser maravilhoso. Ou desastroso S o Brasil escolher como critrio para avaliar o seu Pan-Americano a ltima edio dos Jogos, na e Repblica Dominicana, dificilmente se sair mal. Os Jogos de 2003 foram problemticos desde a preparao at durante as competies. A quatro meses do incio dos Jogos, apenas 30% das instalaes esportivas estavam prontas. Boa parte no ficou pronta a tempo. Provas de natao, por exemplo, tiveram de ser canceladas por no haver local para se realizarem. No Pan de S anto Domingo, essencialmente, faltou dinheiro. No , como vimos, o que ocorre no Rio de Janeiro. verdade que, quando se trata de Olimpadas, as previses originais de gastos nunca so seguidas. No que decupliquem, mas comum oramentos crescerem e at duplicarem. o que j acontece na organizao dos Jogos Olmpicos de Londres, em 2012. O Parque Olmpico foi orado em 3,6 bilhes de euros, mas uma nova avaliao do projeto estima que v custar o dobro. Vale ressaltar, o Parque Olmpico ser construdo em uma rea degradada da cidade. Outra diferena que, por l, o aumento no oramento tratado como escndalo. Cada pas tem a sua cultura. Engana-se quem pensa que o Comit Olmpico Internacional (COI) esteja livre de denncias de irregularidades. Os franceses questionam a escolha da capital do Reino Unido e acusam integrantes do COI de corrupo. S peculiaridades, como as que diferenciam chineses de brasileiros, que revelam as culturas. Por o exemplo, j se pode comprar ingressos para as Olimpadas de Pequim, em 2008, mas ainda no possvel compr-los para o Pan do Rio, daqui a cinco meses. Na questo do oramento, Pequim anunciou que gastar 2 bilhes de dlares para os custos operacionais dos Jogos. Mas, provavelmente, despendero muito mais para melhorar a infraestrutura da cidade. Realizar Jogos Olmpicos pode trazer benefcios permanentes para uma cidade, como em Barcelona ou Sydney. Mas, tambm, prejuzos estrondosos, como em Montreal ou Atlanta. Para a edio de 2004, Atenas anunciou que gastaria 1,9 bilho de euros, mas acabou consumindo mais de 9 bilhes. Um escndalo, que tornou esses os Jogos Olmpicos mais caros da histria. Por enquanto.
69
O exemplo da BOMBA ATMICA

Fonte: HSM Management 50 maio-junho 2005
O grande especialista em liderana Warren Bennis diz, em entrevista exclusiva, que o Projeto Manhattan, de desenvolvimento da bomba, talvez seja o modelo mais completo de equipe que gera resultados sob presso Em seu livro Os Gnios da Organizao, Warren Bennis relata que, em pesquisas sobre o comportamento dos lderes bem-sucedidos, descobriu que no era apropriado considerar separadamente o trabalho em equipe e quem o conduz. Motivo? As melhores equipes, as que geram as mudanas mais significativas, nascem da unio respeitosa entre um lder capaz e indivduos brilhantes, mais que dirigir, a funo do lder consiste em organizar o talento, ou o gnio. O renomado professor da University of S outhern California deixa claro que no acredita no lder herico e solitrio que, contra o vento e as mars, supera os obstculos. E mais: a obsesso generalizada por lderes extraordinrios, segundo Bennis, pode ter como contrapartida a desvalorizao do trabalho em equipe. Como enfatiza o autor nesta entrevista, a cooperao cada vez mais importante. S no imaginrio coletivo, o capito solitrio vence o vento e as mars, e, a realidade demonstra que ele costuma estar acompanhado de um grupo de marinheiros excepcionais. Em seu livro Os Gnios da Organizao e em outros artigos seus sobre liderana, o sr. se refere ao Projeto Manhattan, o que inusitado. Por qu? O Projeto Manhattan o exemplo de liderana e trabalho em equipe mais importante do sculo 20. S a direo de Robert Oppenheimer, um grupo de cientistas talentosos, nenhum com mais ob de 32 anos, foi reunido em lugar secreto, Los Alamos, para criar uma arma que mudaria o curso da histria. S eus primeiros encontros foram realizados em janeiro de 1943 e, em pouco mais de dois anos, haviam produzido a bomba atmica. E por que o sr. o considera um caso emblemtico? Por vrios motivos. Oppenheimer foi capaz de motivar seu pessoal e conduzi-lo para alm do imaginvel, arriscando-se a experimentar algo cujos resultados eram incertos. Teve a credibilidade e a capacidade necessrias para impulsionar o grupo a lanar-se rumo ao desconhecido. Era a primeira vez que esses cientistas e engenheiros trabalhavam juntos e, diferentemente do que acontecia na maioria dos projetos, muitos nem sequer sabiam por que estavam ali. Um bom lder o que ajuda os demais a encontrar uma definio de sucesso que seja comum a todos. Oppenheimer demonstrou isso quando o grande fsico Richard Feynman, que na poca tinha uns 23 anos, reclamou e lhe pediu que lhes revelasse o que estava acontecendo. Eles passavam horas fazendo clculos sem saber para que os usariam, estavam submetidos a uma censura rgida e eram seguidos por agentes do FBI cada vez que saam de Los Alamos. Feynman insistiu que era preciso confiar no pessoal, dar um sentido ao que faziam e lembrar-lhes o que era importante. Oppenheimer cedeu a sua reivindicao e explicou aos cientistas qual era a meta: criar uma arma que deixaria o chamado mundo livre em condies de ganhar a S egunda Guerra Mundial. Ao transmitir essa informao confidencial, deu um sentido ao trabalho deles Gerenciamento de projetos
70 Apesar das caractersticas to particulares do Projeto Manhattan, o sr. sugere em seus trabalhos que possvel extrair dele inmeras lies para o mundo empresarial. Quais so? Robert Oppenheimer no era o cientista mais brilhante do grupo de engenheiros, fsicos e qumicos alguns obtiveram, anos depois, o Prmio Nobel. No entanto, ele foi capaz de deixar de lado seu ego e incentivar o talento dos demais, uma qualidade fundamental nos lderes empresariais. Nenhum presidente de uma companhia de atuao mundial e complexa consegue saber tudo. Oppenheimer se pautava por dois princpios. O primeiro: Nenhum de ns to inteligente quanto todos ns. O segundo: S omos capazes de explicar ao resto de ns o que que no sabemos. Assim, conseguiu integrar em uma mesma equipe cientistas de disciplinas distintas, que tinham antecedentes dspares, e obter o melhor de cada um deles. Essa a essncia da liderana. Oppenheimer j tinha dado alguma vez sinais de sua capacidade de liderar? Ele no tinha experincia, e isso o interessante. No havia cursado escolas de administrao nem havia se capacitado na conduo de equipes. Mas, mesmo assim, ele conseguiu que os cientistas lhe respondessem, porque era um deles e conhecia a maneira de pensar daquelas pessoas. Como foram escolhidos os cientistas? Oppenheimer desempenhava duas funes docentes: no California Institute of Technology (CalTech), um dos centros de pesquisa mais importantes dos EUA, e na University of California, em Berkeley, outra instituio de primeiro nvel em fsica nuclear. Alm disso, Oppenheimer possua contatos nas principais universidades do Reino Unido, Itlia, Alemanha e outros pases, pois conhecia os cientistas que realizavam pesquisas em fsica nuclear. Ele os escolheu a partir de sua experincia pessoal. Que obstculos ele teve de enfrentar? Por um lado, os relacionados dificuldade prpria da tarefa e ao fato de convocar pessoas provenientes de diferentes campos do conhecimento, no habituadas a trabalhar em equipe. O desafio era conseguir que esses completos estranhos colaborassem e perseguissem um objetivo comum. A segunda dificuldade era externa, relacionada segurana. O chefe de Oppenheimer era o general Leslie Groves, que desconfiava dele, porque a esposa do cientista e um de seus melhores amigos tinham simpatias comunistas. No entanto, Oppenheimer convenceu Groves e conseguiu que este jogasse a seu lado e o apoiasse. S a asa do general, ficou protegido dos que ob poderiam acabar com o projeto. Separar o grupo de fontes de distrao, como em Los Alamos, contribui para sua coeso? No necessrio isolar um grupo, mas importante proteg-lo e fazer com que seus membros estejam fisicamente prximos. Atualmente se incentivam as equipes virtuais, mas no h nada como o trabalho cara a cara. O fato de os integrantes da equipe serem to jovens desempenhou papel importante? Os engenheiros e cientistas dedicavam muitas horas por dia ao trabalho e avanavam a um ritmo difcil de manter. Tambm no tinham vida privada, porque suas famlias no viviam na base militar. Claro que eram tempos de guerra.
71 Houve outros custos para eles? Houve um mais sutil, relacionado a fabricar uma arma de destruio macia que matou milhares de pessoas no Japo. Foi preciso enfrentar uma questo tica, e muitos passaram o resto da vida perseguidos pelo fantasma de terem sido a causa de semelhante destruio. O que normalmente acontece quando um grupo brilhante alcana sua meta? Ele se dissolve ou embarca em um novo projeto? Em geral, os membros de uma equipe quente como a do Projeto Manhattan sentem alvio uma vez cumprida sua misso. Descansam e recuperam energias, mas poucas vezes voltam a encontrar um grupo to significativo. Que outras experincias de trabalho em equipe, comparveis de Los Alamos, o sr. Poderia mencionar? OS kunk Works, grupo de elite de engenheiros aeronuticos e subcontratados da Lockheed que projetou avies radicalmente diferentes. O Palo Alto Research Center (PARC), laboratrio da Xerox no qual surgiram muitas das invenes que tornaram possvel o computador pessoal. E a campanha Clinton-Gore de 1992, que levou presidncia dos Estados Unidos o primeiro democrata depois de Jimmy Carter. Nos trs casos, houve um lder que deixou de lado seu ego, apoiou-se na capacitao de toda a equipe e ajudou a criar uma definio de sucesso comum a todos. Diante da complexidade do mundo atual, fundamental coordenar equipes para responder a desafios como o desastre do tsunami asitico. Ningum pode fazer tudo sozinho. No futuro, haver necessidade de muitos projetos Manhattan para alcanar sucesso, principalmente no mundo corporativo. A entrevista de Viviana Alonso, colaboradora de HSM Management
3.5 Voc = seus Projetos

Fonte: Revista Voc S.A. Agosto 99. Por Tom Peters
Aprendi sobre o futuro do trabalho vivendo de projetos. Projetos do tipo que se faz rotineiramente em uma empresa prestadora de servios. H mais tempo do que me permito lembrar, apresentei-me na sede da Mckinsey & Co., em S Francisco, para o meu primeiro dia de o trabalho como consultor profissional. Comecei a trabalhar s 9 horas da manh e, no mesmo dia, s 3 da tarde, estava em um avio indo para Clinton, no estado de Iowa. Misso: trabalhar em um projeto numa usina petroqumica que envolvia um investimento de 150 milhes de dlares. Na ocasio, eu no era capaz nem mesmo de soletrar a palavra "petroqumica", ainda que me ajudassem. Mas essa era a rotina de quem trabalhava com "projetos". Avance 25 anos no tempo.Todo o trabalho desenvolvido hoje em dia por executivos considerado um projeto. O nico fato interessante que influencia a todos ns que o trabalho est sendo reinventado. A revoluo do trabalho que transformou a vida dos operrios nos anos 70 e 80 est finalmente chegando aos escritrios e cubculos dos executivos. Para o operrio, a fora propulsora das mudanas foi a automao das fbricas, que passaram a usar como ferramenta as Gerenciamento de projetos
72 mquinas programveis. Para quem trabalha em escritrio, essa fora tem sido a tecnologia dos computadores: sistemas de planejamento de recursos organizacionais, groupware, intranets, extranets, sistemas especialistas, a Web e o comrcio eletrnico. Aps dcadas de descaso indiscriminado, as empresas esto finalmente enfrentando o problema da baixa produtividade de seus funcionrios - e compreendendo que precisam reorganizar o trabalho de maneira completamente nova. Os velhos mtodos de trabalho so lentos demais e complicados demais. difcil control-los. difcil mensurar seu valor. Paralelamente, os prprios executivos esto se dando conta de que precisam repensar a prpria natureza do trabalho. S e desejam ter o que fazer no futuro, precisam ser capazes de demonstrar de maneira clara, precisa e convincente como podem agregar valor. A resposta, alis, a nica: ter um projeto. No qualquer projeto, mas sim um que se inclua naquilo que eu e meus colegas batizamos de "Grandes Projetos": projetos que agregam valor, que so importantes, que fazem diferena, que deixam um legado e, claro, que transformam voc em uma estrela. Projetos que se destacam so o futuro do trabalho, porque mais de 90% dos cargos executivos esto atualmente ameaados e passando por um processo de transformao, que tornar quase impossvel sua identificao ou os eliminar por completo. Arquitetos, contadores, desenhistas grficos, advogados, consultores e todos os demais trabalhadores de empresas prestadoras de servios "oficiais" sabem o que significa a rotina dos projetos. Como profissional, aos 56 anos, posso honestamente dizer que vivo a nova frmula: Eu = Meus Projetos. Contudo, essa idia completamente nova para os executivos clssicos que trabalham nos departamentos de recursos humanos, nos departamentos financeiros e em todos os demais departamentos das empresas mdias dos Estados Unidos que atuam nas reas de fabricao, produo e operao. Qualquer trabalho que possua um valor econmico um projeto. Pelo fato de o trabalho por projeto estar se tornando to importante, algumas regras so necessrias para que se pense sobre esse mtodo de forma correta: O trabalho por projeto o veculo pelo qual os fracos se tornam fortes. Esquea os "programas de gerncia participativa". Em vez disso, participe voluntariamente de qualquer projeto, mesmo ruim, que aparea. Organize a festa de Natal do escritrio. (Transforme esse evento desagradvel em uma festa que transmita a todos os funcionrios uma mensagem do tipo "obrigado pelo excelente ano!") Trabalho por projetos o futuro da empresa, um futuro que est s esperando para ser descoberto. Em algum lugar, dentro da empresa, algum est trabalhando anonimamente em um projeto que, daqui a dez anos, todos reconhecero como tendo sido o momento de maior orgulho para a corporao. Algum est criando a linguagem Java, projetando o iMac, relanando o Fusca, criando o Mach3. Por que esse algum no voc? No permita nunca que um projeto se torne montono para voc. S objetivo trabalhar eu constantemente com grandes pessoas, em grandes projetos, para grandes clientes. Como saber quando seu projeto importante? Todas as semanas, faa a si mesmo e a seus colegas de equipe as seguintes perguntas: estaremos nos gabando desse projeto daqui a cinco anos? S as chances e de sucesso so pequenas, o que podemos fazer - imediatamente! - para melhor-las? Quando se trata de sobreviver de projetos, recrute seus colaboradores como se fosse um gerentegeral e invista como se fosse um capitalista ousado. Atualmente, o trabalho se resume a duas Gerenciamento de projetos
73 coisas: talento e projetos. S voc responsvel por um projeto, deve pensar como um gerentee geral de uma franquia da NBA, a liga nacional de basquete dos Estados Unidos: voc tem que preencher 12 vagas com os melhores jogadores que puder recrutar. E quando se trata de escolher seus projetos, voc precisa pensar como um capitalista ousado: apostar em pessoas audaciosas que apresentem projetos inovadores. Quando se trata de Grandes Projetos, preciso ter em mente um fato essencial. Contradizendo toda a literatura sobre gerenciamento de projeto e todas as listas de conferncia de software de projetos, o objetivo do exerccio no realizar um "bom trabalho" de gerenciamento do projeto. O objetivo usar cada projeto que chegue s suas mos como uma oportunidade para criar maneiras novas e surpreendentes de resolver velhos problemas. Para fazer isso, preciso que voc compreenda os quatro passos concernentes a todos os Grandes Projetos: 1.Buscar e criar um Grande Projeto; 2.Vend-lo; 3.Execut-lo; 4. Pass-lo a outras pessoas - para que voc possa se dedicar ao seu prximo projeto. Descobrindo e criando seu grande projeto S Grande Projeto, neste exato momento, est l fora, esperando por voc. Tudo o que voc eu precisa fazer encontr-lo, identific-lo e, ento, cri-lo. bastante simples... e tambm bastante difcil. Afinal, como reconhecer seu Grande Projeto quando voc se deparar com ele? E, aps reconhec-lo, o que fazer para dar forma a esse projeto, desenvolv-lo e transform-lo em um Grande Projeto? Para responder a essas perguntas e para que voc se mantenha no caminho certo, relacionamos a seguir quatro passos que precisam ser dados para fazer com que seu Grande Projeto se torne uma realidade, uma armadilha que deve ser evitada para que ele no fracasse e cinco critrios que voc pode usar para avali-lo. Os Quatro Passos Primeiro Passo - Faa o "teste da importncia". Nenhum projeto digno de ser comentado aconteceu sem uma boa dose de entusiasmo. Ponto final. Assim, quando voc comear a avaliar o valor de um projeto potencial, faa a si mesmo uma srie de perguntas que determinam o grau de entusiasmo envolvido: Quais so meus interesses? O que importante para mim? O que importante para a minha empresa? Se uma idia para um projeto se mostra pobre e fraca - apenas semelhante a uma continuao do que j existe - no vale a pena perder tempo com ela? Um Grande Projeto tem que atender ou criar uma necessidade urgente - ou ser capaz de redefini-la, tornando-a urgente. Os maiores projetos, os mais audaciosos, estimulantes e inovadores, geralmente surgem da necessidade premente de uma equipe ou empresa tomar uma atitude para mudar o jogo. S o eja lanamento de um produto novo e sensual, a criao de uma campanha publicitria inovadora ou a mudana da logstica e das regras de servio em seu nicho. Esses so exemplos de projetos que deixam um legado, projetos em que todos brigam para participar - ou pelo menos estar prximos o bastante para ganhar a camiseta comemorativa que comprova que fizeram parte dele!
74 Mas h uma outra questo. Os Grandes Projetos, especialmente aqueles que podem realmente mudar o futuro, carregam grande emoo. Portanto, quando chegar a hora de identificar se um projeto importante para voc, confie em suas emoes. Escute seu estmago e seu corao. Eles lhe diro se um determinado projeto pode gerar aquela palpitao e aquela percepo aguada capazes de suscitar em voc a disposio de arriscar sua reputao e um precioso ano de sua vida. Segundo Passo - Este passo uma conseqncia do primeiro: nenhum projeto to banal que no possa se tornar um Grande Projeto. J vi uma pessoa, a quem foi designada uma funo que supostamente no traria possibilidade de crescimento profissional (arrumar um depsito), transformar esse projeto em uma oportunidade de redesenhar o sistema de distribuio da empresa. Com isso, ela obteve o passaporte para assumir maiores responsabilidades e projetos mais ousados. Foi preciso apenas seu envolvimento e entusiasmo com o trabalho (veja o Primeiro Passo), e sua obstinao em considerar esse projeto como uma excelente oportunidade. Como isso aconteceu? Quando o projeto de arrumao do depsito foi apresentado para nossa Entusiasmada Lder de Grandes Projetos (ELGP), ela concluiu rapidamente que o problema no era a baguna do depsito, e sim a sua organizao ineficiente. Era isso o que o tornava necessariamente bagunado. Uma simples arrumao no seria capaz de resolver o problema principal: o depsito precisava de uma reorganizao. Essa concluso levou a moa a buscar alguns modelos de excelncia em organizao cuidadosamente selecionados para promover seu aprendizado (assim como tambm o de um seleto grupo de pessoas repentinamente interessadas na arte da organizao de depsitos). Uma de suas principais lies: a organizao do depsito deveria levar em considerao tanto as peas que eram recebidas dos fornecedores quanto as que eram distribudas para os clientes. Assim, pouco tempo depois de ter sido designada para realizar a tarefa, a funcionria acabou criando a necessidade urgente de um novo sistema de distribuio. Um sistema que atendesse perfeitamente ao depsito reorganizado - um depsito que se mantinha arrumado graas aos novos processos criados, que se encaixavam perfeitamente ao novo sistema de distribuio. assim que transformamos uma tarefa menor em um Grande Projeto. Terceiro Passo - Para uma pessoa realmente envolvida na realizao de projetos, qualquer coisa encerra uma valiosa oportunidade de aprendizado. Richard Branson, o entusiasmado e ousado presidente do Virgin Group, sempre disposto a tentar novas idias e alternativas, acredita que o mundo est cheio de projetos esperando para ser descobertos. S principal ferramenta de ua prospeco de projetos: uma srie aparentemente interminvel de cadernos de anotaes onde escreve cuidadosamente suas observaes sobre tudo o que encontra pela frente. Nesses cadernos de anotaes - que j devem somar mais de uma centena - encontram-se todos os tipos de observaes sobre projetos que esto esperando para se tornar realidade. Karl Weick, o brilhante professor de psicologia e comportamento organizacional da Universidade de Michigan, criou seu prprio sistema de prospeco: seu casaco esporte se assemelha a um arquivo. Ele enche os bolsos com todo tipo de papel em que anota suas observaes guardanapos, caixas de fsforos, maos de cigarro. Ento, uma vez por semana, esvazia seu arquivo de tweed e transfere as observaes para um lugar seguro. S voc est sempre observando, est sempre aprendendo. E, ao longo do processo, estar e coletando idias, caminhos e pontos de partida que mais tarde podero se transformar em Grandes Projetos. Abra os olhos e comear a enxergar material para projetos em toda parte. E mais, anotar tudo o que se v ensina outra lio de projeto essencial: pequenas coisas so Gerenciamento de projetos
75 importantes. Por exemplo, o design importante. Quando estiver procura de entusiasmo para o seu projeto, certamente o encontrar no design. E o entusiasmo pode estar em pequenas nuanas: um lampejo de humor pode transformar uma conversa completamente banal em uma expresso pessoal de ateno. O entusiasmo tambm pode se traduzir na arte da simplificao - como, por exemplo, transformar um formulrio insensato que obriga os funcionrios a decifrar jarges desnecessrios em um conjunto simples de declaraes e itens a serem anotados. Essa exatamente a especialidade das pessoas que trabalham na diviso de Comunicaes S implificadas da S iegel & Gale Inc, sediada em Nova York. Elas so capazes de pegar uma coisa desordenada e confusa, como uma conta de carto de crdito, transform-la numa comunicao fcil de ser lida e entendida, e apresent-la de forma simptica ao cliente. Isso faz parecer que o banco que envia o extrato o tipo de instituio financeira que realmente presta um servio! S e estudar a abordagem da Siegel & Gale - ou simplesmente olhar as placas de rua que orientam voc - aprender uma lio essencial: os melhores tipos de design, assim como os melhores tipos de projetos, no chamam a ateno para si mesmos. Utilizam-se de pequenas nuanas para demonstrar a sensibilidade e a suscetibilidade - a autenticidade - das pessoas que trabalharam neles. Quarto Passo - Faa mudanas super-rpidas para refinar o seu Grande Projeto. A 3M construiu uma empresa baseada em uma simples abordagem: faa um pouco, tente um pouco, venda um pouco - e depois repita os mesmos passos. A forma mais rpida e inteligente de conseguir definir e aperfeioar o seu projeto praticar a arte de fazer prottipos rpidos. No deixe seu projeto escondido entre seus trabalhos pessoais, at poder aperfeio-lo e, s ento, exibi-lo. Em vez disso, faa um prottipo simples e mostre-o a alguns membros da equipe. Oua a opinio deles; depois refaa o prottipo. Mostre a eles novamente. Voc estar fazendo duas coisas ao mesmo tempo: aperfeioando seu projeto e demonstrando o seu valor (afinal, voc incorporou a opinio deles). Faa um pouco, tente um pouco, venda um pouco - assim, desde o incio voc estar elaborando e vendendo seu Grande Projeto simultaneamente. A armadilha A armadilha que voc deve evitar ganhar muito dinheiro, muito depressa, com o projeto. Isso a pior coisa que pode acontecer a um projeto (acredite). O dinheiro vai mat-lo rapidamente. Primeiro, ele alivia a presso. Nada substitui a mentalidade de pedir emprestado na fase inicial de todo projeto. S no tiver dinheiro suficiente, voc tem que inovar as formas de resolver os e problemas que voc resolveria, caso fosse possvel, simplesmente comprando uma sada. Voc tem que trabalhar mais prximo a seus clientes e a seus fornecedores - e, conseqentemente, eles se tornam parte do projeto desde o comeo. Tem que adotar a atitude dos piratas: ns contra eles! Vamos nos adiantar ao, aos pensamentos e aos sonhos de todos, porque no temos dinheiro para esbanjar. S egundo, se desde o incio voc obtm dinheiro de patrocinadores internos ou externos, ter que ouvi-los desde o comeo. Eles simplesmente compraram o direito de se sentar sua mesa e interferir em sua vida. E a ltima coisa que um Grande Projeto precisa de uma pessoa com dinheiro dando especificaes, decidindo onde vale a pena investir mais tempo e dinheiro, e exaurindo o entusiasmo pelo projeto. Para evitar o problema, viva modestamente e pense grandiosamente. Gerenciamento de projetos
76 Os Cinco Critrios Voc pode resumir um projeto a uma simples lista de cinco critrios: Grande! Lindo! Revolucionrio! Impressionante! Extraordinrio! (O ltimo critrio vem como cortesia do livro de Ken Blanchard e S heldon Bowless, Raving Fans: A Revolutionary Approach to Customer S ervice, William Morrow, 1993.) Afinal de contas, isso engloba tudo. Todos sabemos o que esses cinco termos significam, certo? Mas raramente - ou melhor, nunca - usamos essa linguagem entre as 9 e as 17 horas. J tempo de mudarmos isso. Escreva os cinco termos em um carto e coloque-o em sua carteira. Quando tiver que avaliar se um projeto proposto corresponde s expectativas - ou pode ser aperfeioado a fim de vir a correspond-las - simplesmente tire o carto da carteira. Voc saber se ele corresponde ou no. Como vender seu novo projeto S voc consultar a literatura sobre gerenciamento de projetos cuidadosamente, garanto que no e encontrar a palavra vender. As pessoas que trabalham no mundo de gerenciamento de projetos falam sobre todas as outras coisas - desde grficos PERT (PERT a sigla para avaliao de programa e tcnica de reviso. Fiz mestrado sobre esse assunto), grficos Gantt e cronogramas, at "especificao insidiosa" e "metodologia de gerenciamento de risco". Raramente voc vai ouvir essas pessoas falarem sobre a necessidade de vender seu projeto. Parece que todos supem que basta que um produto seja bom para vender bem. Embora os especialistas em gerenciamento de projetos no valorizem a necessidade de vend-los, h um grupo de pessoas no mundo dos negcios que realmente entende a questo crtica que a venda do projeto representa. S aqueles que trabalham nas "verdadeiras" empresas de servios o profissionais: todo consultor de gerenciamento, todo mago de agncia de propaganda, todo corretor da bolsa de valores um vendedor. Eles esto vendendo sua opinio especializada, sua reconhecida percia e seus servios brilhantes a clientes externos. E esto vendendo sua confiabilidade, segurana e talento para os colegas de trabalho. apenas uma outra parte de nosso velho amigo The Brand Called You, "A Marca Chamada Voc". S projeto e sua marca eu caminham juntos: ambos dependem da habilidade que voc tem para vender a si mesmo e seu projeto. S quiser que seu Grande Projeto se torne realidade, aprenda a vend-lo - de forma e inteligente, persistente e desde o comeo. Um ELGP (Entusiasmado Lder de Grandes Projetos) tem que dominar duas habilidades essenciais de venda: argumentao e organizao da comunidade. A arte da argumentao resume o que chamamos de "conversa de 2 minutos no elevador". Voc est no elevador a caminho da sua sala. A porta se abre e o presidente da empresa entra. Enquanto a porta se fecha vagarosamente, ele olha para voc fixamente e pergunta: "Em qual projeto voc est trabalhando que o torna especial para esta empresa?" Voc est sozinho no elevador com a pessoa mais importante da empresa e tem 2 minutos para responder exatamente por que seu projeto importante. Qual o seu argumento? Claro que voc fica com um frio na barriga e com o corao saindo pela boca - mas a questo da argumentao no elevador no como lidar com a presso. A questo a comunicao. E a preocupao. Voc conseguiria reduzir o conjunto de problemas incrivelmente complicados com os quais est lidando em seu projeto a trs pontos principais, de forma que qualquer um pudesse entend-los imediatamente? Melhor ainda, voc poderia explicar seu projeto usando uma metfora perfeita sem o uso de slides em Power Point? Por exemplo: "Quando tivermos Gerenciamento de projetos
77 terminado esse projeto sobre a satisfao do cliente, estaremos to ntimos que nossos clientes sero nossos companheiros de bungee-jumping." Voc saber que conseguiu uma metfora perfeita quando receber as camisetas, para voc e sua equipe, com os dizeres "A turma do bungee-jumping" - cortesia do prprio CEO. A outra habilidade essencial do ELGP a organizao da comunidade. uma arte que floresceu na dcada de 60 sob a tutela de ativistas legendrios como S Alinsky, que escreveu Rules for aul Radicals (Random House, 1971), e o sindicalista Cesar Chavez. As lies ensinadas por eles tambm se aplicam a seu projeto. A organizao da comunidade tem origem no apoio das pessoas. Trata-se de como identificar, entre as que esto a sua volta, aquelas com quem voc possa criar uma causa comum e apaixonante. Trata-se de como ignorar a sabedoria convencional das diretrizes da empresa e, em vez disso, jogar o jogo com regras bem diferentes. Por exemplo, a prtica convencional instrui os futuros ELGPs a conseguir que o alto gerenciamento "compre a idia de seu projeto" desde o incio. A frase clssica diz: "Consiga o apoio de seu chefe e voc conseguir o sinal verde de que precisa". No! No! E no! Nunca procure seu chefe muito no incio do projeto. E nunca v at seu chefe antes de conseguir organizar o apoio das pessoas que vo trabalhar com voc, apoio indispensvel para fazer com que o projeto se torne realidade. Organizar a comunidade no significa observar seu organograma para ver o que o chefe pensa. Significa olhar a seu redor para verificar quem voc pode convencer a endossar o projeto; olhar para ver quem voc pode incluir na lista de sua causa; e olhar a sua volta para verificar quem est em uma rea essencial e quem pode contribuir com talento. No se preocupe com a aprovao de seu chefe. Organize a comunidade e, quando for falar com seu chefe, ele reconhecer que voc j conseguiu a aprovao das pessoas talentosas da organizao. O segundo engano estratgico que voc no pode se dar ao luxo de cometer gastar precioso tempo, e uma parca energia emocional, preocupando-se com seus inimigos. S seu projeto for e genuinamente um Grande Projeto, voc certamente ter inimigos. (O axioma do projeto: qualquer coisa que valha a pena ser feita enlouquece o sistema.) Esquea seus inimigos! Concentre-se na obteno do apoio de seus amigos. Consiga a adeso de pessoas importantes que emprestem seu nome e influncia para o projeto. Lembre-se: voc nunca conseguir mudar a opinio de seus inimigos. A melhor coisa a fazer cerc-los daqueles que o apiam de forma entusiasmada e determinada. Como executar seu grande projeto Agora que voc j trabalhou duro para identificar e vender seu Grande Projeto, est pronto para a fase trs: hora de execut-lo! Mas no assim que funciona - no exatamente. S omente nas matrias de revista que voc pode dividir o trabalho em fases distintas e metdicas. Na execuo do trabalho essas coisas se sobrepem, caminham juntas, se fundem, se separam e se fundem novamente. Na vida real, o DNA do Grande Projeto est presente em cada uma das quatro fases: a diferena est na relativa concentrao em cada fase. Portanto, enquanto voc est comeando seu Grande Projeto, tambm j est fazendo algumas coisas que sero importantes em uma fase posterior. Como, por exemplo, estar praticando uma boa argumentao e organizando a comunidade antecipadamente. E, ao mesmo tempo em que estiver vendendo seu Grande Projeto, estar fazendo algumas das coisas necessrias para execut-lo - como fazer o prottipo, ouvir opinies e aperfeio-lo. Lembre-se sempre: voc no deixa de executar algumas atividades simplesmente Gerenciamento de projetos
78 porque a nfase muda. mais uma questo de reconhecer em que ponto da evoluo do projeto voc est, para que voc possa concentrar o tipo de esforo correto na hora certa. Na fase de execuo, certifique-se de concentrar o tipo de esforo correto seguindo trs importantes regras que devem ser "observadas" e trs igualmente importantes que devem ser "evitadas". Pense na execuo como uma srie de prottipos. A vida uma srie de mudanas sucessivas. Seu projeto nunca estar perfeito na primeira vez (por sinal, nem na 21o ) - nunca. Guard-lo para si at que esteja "perfeito" simplesmente uma bobagem. Esse um jeito infalvel de garantir que quando voc o apresentar, alm de o projeto no estar perfeito, voc no ter tempo, energia ou apoio suficientes para retom-lo e aperfeio-lo. Grandes projetos sobrevivem de retornos instantneos e ciclos de ajustes. Esta uma forma de encarar a situao: um prottipo gigante em tempo real. Mas o hbito de usar um rpido retorno e ciclos rpidos de ajuste antecipa a Web. A HewlettPackard foi a pioneira nessa prtica para desenvolver vrios produtos inovadores: as pessoas construam um prottipo e o deixavam mostra para que os outros comentassem sobre o produto. Retornos instantneos possibilitam ciclos de ajustes instantneos. Quanto maior o nmero de iteraes a que voc se submeter, mais rpido poder executar seu projeto. David Kelley, um gnio em design e CEO da Ideo, expressou-se bem ao dizer: "Fracasse sempre para ter sucesso mais rpido". Pode parecer estranho, mas o trabalho da execuo relaciona-se, na verdade, com o fracasso. Ento, comemore o fracasso! Toda semana d um grande trofu como prmio ao membro da equipe de projetos que fizer a "besteira da semana". Por que no? Pense, viva, durma, coma e respire pensando em seu cronograma. J est na hora de pensar seriamente em terminar seu projeto. Assim, concretize essa coisa indefinida que voc chama de "seu projeto" elaborando uma lista de coisas a serem feitas. O que precisa ser feito hoje? E amanh? E na prxima semana? Desenvolva um mtodo simples e fcil para avaliar o progresso do projeto. Pode ser algo to simples quanto o uso de um fichrio com um divisor para cada etapa do projeto. S voc quiser um bom exemplo deste mtodo, leia o livro de Guy Kawasaki, The e Macintosh Way (Addison-Wesley, 1989). O livro inclui o plano completo de apresentao da Macintosh - um exemplo da lista de coisas a serem feitas. Domine tambm a arte de fazer reunies de 15 minutos - uma sesso diria "dinmica" em que cada membro do projeto faz um rpido relatrio do progresso, identifica a descoberta do dia ou grita desesperadamente por socorro. S a CNN consegue organizar a pauta de matrias de um dia e inteiro de transmisso em 30 minutos (como faziam em 1993, quando visitei sua sede), ento voc certamente pode organizar seu projeto em 15 minutos. Faa com que seja realmente divertido. A lista de coisas a fazer serve para que voc tenha certeza de ter alcanado a fase final do projeto. Mas isso no quer dizer que voc deva tolher sua personalidade. Nunca perca o senso de diverso que uniu a equipe no comeo. Lembre-se sempre de comemorar para manter a alegria ao desenvolver um Grande Projeto. Nenhuma conquista to pequena ou insignificante que no justifique uma pequena comemorao. medida que voc alcanar seus objetivos e completar o fichrio com as conquistas de sua equipe de projeto, lembre-se da pausa que revigora. No precisa ser algo excepcional. Pode ser o suficiente para manter as tropas entusiasmadas.
79 To importante quanto essa lista com os trs itens a serem observados aquela com os trs itens a serem evitados: os maus hbitos nos quais as equipes escorregam quando chega a hora de executar o projeto - o vilo que pode pr a perder at mesmo o mais promissor dos projetos. No fale demais. Voc vai passar boa parte de seu projeto falando sobre ele. Mas a realidade na maioria das empresas que a execuo do projeto freqentemente se transforma em conversar sobre a execuo, ou seja, falar em vez de fazer. A equipe pra de construir prottipos e de fazer revises e comea a falar sobre o que precisa acontecer em seguida. Ou as equipes gastam muito tempo em reunies, conversando uns com os outros, e no passam tempo suficiente no mercado conversando com os usurios finais. Pense sobre isso em termos matemticos: se a proporo conversar/ fazer da maioria das equipes de 70% para 30%, ento voc deve reverter esses nmeros para que sua equipe faa 70% e converse 30%. No pare de vender. Aqui est um outro modo de encarar a execuo: trata-se "apenas" de um aumento de vendas (sem brincadeira). S trabalho durante a fase de execuo desenvolver eu uma base de apoio que possa ser expandida. A execuo nada mais do que reunir cinco adeptos fervorosos que apoiaram voc durante a fase de criao, junto com 15 adeptos fervorosos que aderiram causa durante a fase de venda. E adicionar 45 novos adeptos fervorosos que podem ajudar a levar seu projeto a campo - onde ele possa ser implementado. Nunca pare de vender! Nunca pare de recrutar! E, finalmente, no perca o entusiasmo: no deixe o projeto ficar rido. To importante quanto manter o projeto em andamento torn-lo grandioso. Convenhamos: a execuo de um projeto emocionalmente desgastante. A grandeza do projeto pode se esvair fcil e imperceptivelmente. Depois de algum tempo, voc e sua equipe ficam to cansados que se esquecem do que tornou o projeto grande, lindo, revolucionrio, impressionante e extraordinrio. Voc corre o risco de executar o que pode vir a ser apenas um outro projeto - um "sucesso medocre", como colocou um participante de meu seminrio. (Outra equao: sucesso medocre = morte.) Essa a hora de dar uma parada. Leve sua equipe para espairecer um pouco. Volte aos princpios iniciais e verifique se vocs ainda esto envolvidos emocionalmente. Recrute um novo membro, algum com energia e entusiasmo. Mas no deixe que a energia que deu incio ao Grande Projeto se perca. Como passar o grande projeto para outra pessoa Parabns! Depois do que parecem ter sido - ou realmente foram - meses ou anos de trabalho rduo e muita energia pessoal, o projeto est funcionando. Voc conseguiu: o novo produto est no mercado, o novo servio est disposio dos consumidores, a nova equipe de vendas est a postos, o novo centro de servios para o consumidor est em funcionamento. Agora vem a parte (realmente) difcil. Est na hora de voc passar o projeto para que algum o administre diariamente. Est na hora de voc deixar de lado o projeto em que se empenhou tanto e cuja criao, venda e execuo tantos empecilhos apresentaram, para que ento voc possa comear todo o ciclo criativo novamente. o mais sensato, necessrio e difcil. sensato e necessrio porque, pela minha experincia pessoal, as pessoas que superam obstculos para criar um Grande Projeto raramente dispem das qualidades necessrias para operar esses mesmos projetos. a mesma diferena que, tipicamente, separa um empreendedor de um gerente. Se voc for bom na criao do projeto, na luta e na vitria das batalhas internas do Gerenciamento de projetos
80 "ns versus eles", e em lidar com o turbilho emocional provocado pela conduo do projeto, ento so grandes as possibilidades de que voc no seja a pessoa indicada para gerenci-lo a longo prazo. Alm disso, voc fez o que tinha de ser feito. Voc pode at estar cansado das particularidades daquele projeto e ansiar por um novo desafio. Mas tambm difcil - porque conforme voc aprendeu na prtica, o gerenciamento do projeto o gerenciamento da emoo, e ponto final. Essa uma outra verdade sobre projetos que no nos ensinam na literatura oficial. Mas esta a essncia da questo: projetos so intensamente pessoais. Voc e sua equipe deram o melhor de vocs e de seus relacionamentos para tornar o projeto uma realidade. Quando voc pensa sobre aquele projeto - mesmo que esteja apenas olhando para nmeros em uma folha de papel --, lembra-se de todas as noites que passaram trabalhando nele, dos lanches que comeram no escritrio, das discusses e dos acordos que fizeram. Bem, agora voc precisa dar tudo isso a outra pessoa... Lidar com essa entrega o ltimo teste do ELGP. A primeira coisa a fazer a festa de encerramento. S o gerenciamento do projeto o e gerenciamento da emoo, ento voc e os membros da equipe precisaro de uma comemorao sria para marcar sua conquista. No tenha vergonha: lembre-se de que voc ainda est vendendo o projeto e construindo sua marca. Autorize a elaborao de um histrico do projeto que registre a contribuio dos membros da equipe e que capte as lies importantes que foram aprendidas durante o desenvolvimento do trabalho. E envie notas de agradecimento a todos os que ajudaram, apoiaram e acreditaram no projeto para torn-lo uma realidade. Voc precisar deles novamente - em seu prximo Grande Projeto. Deseje o melhor para seu sucessor e certifique-se de que tudo que voc fizer quando passar o projeto a essa outra pessoa facilitar o trabalho dela. fundamental ter certeza de que o projeto seja um sucesso - e no mostrar que sem voc o projeto rapidamente acabaria. S voc for um grande ELGP, certamente j deve estar buscando sua prxima oportunidade. J e deve ter identificado e selecionado a maior parte de sua equipe (certifique-se de selecionar as pessoas que voc quer, no as que o departamento de recursos humanos oferece). E, se voc estiver seguindo o estilo de observao de Richard Branson - Karl Weick, voc j estar reunindo sua prpria coleo de recortes de jornais, experincias pessoais e pensamentos aleatrios. Tudo isso matria-prima, e est esperando que voc a vasculhe e escolha algo que possa vir a ser seu prximo Grande Projeto. O mais importante que o fim de seu projeto marca sua maior oportunidade: a chance de voc fazer uma auto-avaliao. Chamar o projeto de "bem-sucedido" no o suficiente para captar o real valor da experincia. S voc estiver decidido a fazer dele um sucesso pessoal intenso, precisa e refletir sobre o que o projeto significa para voc. O que voc aprendeu com ele? Em que pontos voc se saiu bem? Em que pontos voc no se saiu to bem? Que habilidades acredita ter desenvolvido? Que habilidades ainda precisa desenvolver? Ao fazer sua prpria avaliao ao trmino do projeto, voc no estar apenas encerrando seu envolvimento emocional e profissional com ele, mas tambm estar dando o primeiro passo para realizar seu prximo projeto. A partir dessa avaliao, voc ter as respostas que o levaro adiante. Voc decidir se quer trabalhar em um projeto que oferea uma gama de novas experincias ou se prefere desenvolver suas habilidades em uma rea na qual j demonstrou sua destreza. Voc deve trabalhar suas fraquezas ou apostar em seus pontos fortes? Ao olhar para seu portfolio, voc pode decidir que Gerenciamento de projetos
81 seu prximo projeto deve conduzi-lo a um novo campo - para que voc possa aprender mais sobre finanas, por exemplo. Ou a um novo papel - para que voc possa atuar mais como membro de uma equipe do que como um lder. Ou a uma nova regio - para que voc possa desenvolver um projeto fora de seu pas. Voc faz a sua avaliao, procura um projeto pequeno com grandes implicaes, faz a pergunta "isso importante?" e d incio novamente ao ciclo de um Grande Projeto. Voc aprendeu a mover-se de projeto em projeto em um mundo onde o trabalho definido por projetos. Voc aprendeu a nova equao do mundo do trabalho: VOC = SEUS PROJETOS . Bem-vindo era dos grandes projetos
3.6 Como acelerar o desenvolvimento de novos produtos

Fonte: Universia Knowledge at Wharton
Est provado que as equipes multifuncionais compostas por indivduos que pertencem a diferentes reas funcionais so fundamentais para a agilizao dos projetos de desenvolvimento de novos produtos. Quem garante isso Pilar Carbonell, da S chool of Administrative S tudies, da Atkinson Faculty, York University, e Ana Isabel Rodrguez Escudero, da Universidade de Valladolid, em recente pesquisa publicada pela Universia-Business Review. A diminuio do tempo de desenvolvimento de novos produtos permitir s empresas manter sua vantagem competitiva ou, simplesmente, garantir sua sobrevivncia. Contudo, as equipes encarregadas desse processo possuem diversas caractersticas que, aliadas a decises da alta direo, produzem um impacto sobre a velocidade de desenvolvimento que merece ser aprofundado. De que modo, por exemplo, isso afeta a experincia da equipe? S er que a proximidade fsica dos membros do grupo ajuda a reduzir o tempo de desenvolvimento do produto? Os membros da equipe devem sempre ser os mesmos ou o ideal seria que fossem trocados? A dedicao em tempo integral ao desenvolvimento permite que o produto chegue antes ao mercado? A fixao de objetivos claros e o respaldo da alta direo contribuem para a acelerao do processo de desenvolvimento? Para responder a essas indagaes, as autoras analisaram os resultados de um questionrio enviado pelo correio a 183 empresas espanholas com mais de 50 empregados e de setores os mais variados. O objetivo do estudo consistia em identificar a influncia da complexidade tecnolgica entendendo-se por projeto complexo aquele que requer uma tecnologia nova e cuja incorporao ao produto representa uma certa dificuldade tcnica sobre a relao existente entre as caractersticas de desenvolvimento de um novo produto e a velocidade requerida para seu desenvolvimento. Para isso, as autoras elaboraram uma pesquisa centrada no estudo de quatro caractersticas da equipe experincia, proximidade, estabilidade e dedicao e duas decises da alta direo clareza de objetivos e apoio ao projeto. Todas essas variveis so tradicionalmente consideradas benficas para a velocidade de inovao, de acordo com as autoras. Contudo, o que mostram os resultados? Como possvel diminuir o tempo de desenvolvimento de novos produtos? Gerenciamento de projetos
82 Uma experincia maior nem sempre melhor Carbonell e Rodrguez observam que temerrio dizer que uma equipe experiente sempre contribui para a acelerao do desenvolvimento de um novo produto, algo que primeira vista poderia parecer evidente. De acordo com as autoras, trata-se apenas de meia verdade. Na pesquisa realizada, elas chegaram concluso de que a experincia ajuda a acelerar os projetos tecnologicamente simples, mas no aqueles mais complexos. Isto acontece porque, no caso de projetos simples, dada a familiaridade e ao conhecimento da tecnologia incorporada, as equipes podem recorrer a seus conhecimentos prvios para identificar as necessidades do projeto. Contudo, projetos tecnologicamente complexos requerem um certo nvel de experimentao, inveno, tentativa e erro. Em outras palavras, so necessrias condutas que podem acabar reprimidas em equipes experientes devido dificuldade que encontram em se desviar de modelos comportamentais preexistentes. Portanto, para o desenvolvimento de inovaes radicais, as autoras assinalam que eliminar a memria da equipe, ou desaprender, pode ajudar na aceitao do nvel de mudana exigido, adotando-se um comportamento mais flexvel e dinmico. Proximidade bom dependendo das circunstncias O estudo revelou tambm que a proximidade fsica pode ser muito til para a acelerao das atividades necessrias colocao do produto no mercado. O trabalho realizado face a face com os demais colegas favorece a soluo de possveis problemas. Por isso, em projetos tecnolgicos complexos, a proximidade acelera a velocidade de inovao. Contudo, nos projetos simples, a comunicao contnua e imediata no s menos necessria, como pode tambm contribuir para complicar a execuo do trabalho e provocar distraes na equipe, explicam Carbonell e Rodrguez. As autoras no detectaram benefcio algum na proximidade fsica entre os membros da equipe no caso de projetos tecnologicamente simples. Flexibilidade na composio da equipe As pesquisadoras acrescentam ainda que, ao que tudo indica, quando uma equipe permanece estvel (isto , quando seus integrantes so os mesmos do incio at o lanamento do produto), possvel realizar o trabalho mais rapidamente, j que no haver ruptura nas atividades decorrentes de mudanas provocadas pela troca de membros e tampouco o risco de perda de conhecimento ou de informao. Todavia, a exemplo do que acontecia em situaes anteriores, tudo depende do grau de complexidade tecnolgica do projeto. Portanto, observam as pesquisadoras, a introduo de um novo membro na equipe no caso de projetos complexos , pode introduzir novos modelos mentais de trabalho necessrios ampliao das perspectivas da equipe. Quanto mais tempo a equipe permanecer unida, maior ser o grau de comprometimento com seus pressupostos, e menor a probabilidade de que sejam questionados internamente. Alm disso, as autoras observam que o nvel elevado de incerteza dos projetos tecnologicamente complexos limita a capacidade de planejamento da empresa e a alocao de pessoal mais adequado desde o incio, por isso as autoras acreditam que seria mais vantajoso trocar alguns membros da equipe conforme necessrio. No caso de projetos tecnolgicos simples, a estabilidade tem um efeito de acelerao do projeto que no se constata nos projetos tecnologicamente complexos, garantem as pesquisadoras.
83 Dedicao, mas sem floreios Deduz-se do estudo que, em projetos tecnologicamente complexos, a dedicao em tempo integral permite equipe obter a concentrao e a motivao necessrias ao seu rpido desenvolvimento. Nos projetos de tecnologia simples, as autoras esperavam que esse efeito fosse menor, mas sua surpresa foi grande ao constatar exatamente o contrrio. A explicao para esse fenmeno, segundo as pesquisadoras, que em casos de projetos simples, os indivduos que trabalham em tempo integral raras vezes tm conscincia de que esto dando uma contribuio notvel ao trabalho, e tendem a adornar o produto com atributos suprfluos. Esse esforo suprfluo, dizem, agrega tempo fabricao do produto. J um compromisso em tempo parcial pode acelerar a execuo de projetos tecnologicamente simples, uma vez que quando os indivduos dividem o tempo entre vrias atividades, existe uma tendncia de se fixar no essencial, de aplicar solues provadas e de deixar de lado os floreios. S qual for o contexto de complexidade tecnolgica de execuo do projeto, as autoras dizem eja que necessrio transmitir s equipes a viso precisa daquilo que se deseja, especificar um ponto no qual os esforos sero centrados, alm de ajudar na criao de fronteiras que limitem tais esforos ao mbito de trabalho previamente ficado. Isto contribui para a acelerao da velocidade de desenvolvimento, uma vez que tem papel importante na propulso de uma aprendizagem rpida. Quando a alta direo contribui de forma negativa No tocante participao da alta direo, Carbonell e Rodrguez observam que ela fundamental para a determinao da velocidade, sobretudo quando se trata de projetos tecnologicamente complexos. S implicao e influncia sobre a velocidade se d principalmente quando a ua natureza das tarefas menos evidente e familiar. Todavia, depois de constitudo o grupo de desenvolvimento, a participao da alta direo em projetos tecnolgicos simples pode constituirse em empecilho, j que seu envolvimento pode acarretar um consumo de tempo adicional, bem como a interrupo das atividades, explicam. Conforme estudos realizados anteriormente, salientam as autoras, nos mercados de mudanas mais rpidas, o respaldo da direo pode ser decisivo para que a equipe no se perca em face da complexidade das tarefas a serem realizadas. Contudo, os resultados obtidos pelo estudo no confirmam a importncia do papel da alta direo em situaes de grandes incertezas. As pesquisadoras atribuem esse dado possvel falta de associao direta entre o apoio da alta direo e a velocidade. Essa relao pode ser mediada pelos prprios fatores de configurao da equipe considerados no estudo. As autoras concluem o estudo com diversas recomendaes. Para agilizar os projetos de tecnologia complexa, preciso que certos membros da equipe trabalhem juntos em tempo integral. Quando essas duas caractersticas localizao prxima e dedicao especial acham-se presentes em uma equipe, podemos falar de uma equipe integrada. Em segundo lugar, Carbonell e Rodrguez advertem que para acelerar os projetos de tecnologia simples, o mais adequado seria apostar em uma equipe experiente, formada pelos mesmos membros no decorrer de todo o projeto e com dedicao em tempo parcial. A proximidade fsica da equipe no relevante para a rapidez de execuo desse tipo de projeto. Por fim, as autoras enfatizam a fixao de objetivos claros e estveis em sua formalizao. Trata-se de um mecanismo pertinente para a execuo do
84 projeto com a rapidez desejada, seja qual for o nvel de complexidade tecnolgica com que se defronte o projeto, concluem.
3.7 Gerenciamento de riscos em projeto: Melhores prticas e desenvolvimentos futuros

Por: Dr David Hillson PMP FAPM FIRM Diretor, Risk Doctor & Partners
O gerenciamento de riscos desenvolveu-se nos ltimos anos para uma disciplina propriamente dita, com sua linguagem/ terminologia, tcnicas e ferramentas prprias. Muitos livros-textos de gerenciamento incluem sees de gerenciamento de riscos e existe uma biblioteca crescente de textos de referncia especificamente devotados ao prprio tema. O valor de uma abordagem estruturada formalmente e pr-ativa para gerenciamento de incertezas foi largamente reconhecida e muitas organizaes procuram introduzir processos para controlar riscos para ter os benefcios prometidos (consulte Newland 1997 sobre as expectativas de benefcios). Mas embora isso faa parecer que gerenciamento de riscos seja uma disciplina madura, ainda est em desenvolvimento e j existem conquistas antes mesmo que plenamente dominada. Um nmero considervel de iniciativas est a caminho para estender as fronteiras do tema e existe um perigo que gerenciamento de riscos possa dissipar e perder a coerncia se algum senso de direo comum no for mantido. Existe um entendimento comum que aceito sobre os principais temas de gerenciamento de riscos, mas novas direes constantemente so exploradas, como podemos ver pela amplitude dos tpicos cobertos nas literaturas. Existem pelo menos trs reas onde necessrio ter um desenvolvimento ativo a curto ou mdio prazo, se o gerenciamento de riscos estiver realmente comprometido em contribuir significativamente para o sucesso dos projetos e negcios. So estas: Integrao de gerenciamento de riscos com o gerenciamento em geral e a cultura corporativa; Aumentar a profundidade nas anlises e ampliar sua aplicao; Incluso do aspecto comportamental no processo de risco. Essas trs reas esto brevemente consideradas na seqncia do artigo, aps uma breve discusso sobre o que atualmente constitui best practices em gerenciamento de riscos. As Melhores Prticas em Gerenciamento de riscos Existem muitos guias prticos e padres definindo diferentes abordagens para gerenciamento de riscos (por exemplo, APM 2004; ICE 2002; AS NZS / 4360 2004; PMI 2004; UK OGC 2002; IRM 2002). Essas cobrem diferentes nveis de gerenciamento de riscos na governana corporativa, dentro do gerenciamento estratgico de portflio, para projetos e tarefas. Enquanto existem alguns elementos comuns nestes assim chamados padres, cada um leva um pouco diferente a abordagem, ento de fato no existe um nico comumente aceito padro para gerenciamento de Gerenciamento de projetos
85 riscos para as melhores prticas. Contudo, todos os processos de riscos seguem os mesmos passos bsicos (embora a terminologia difere entre eles), com os seguintes estgios: Primeiro a fase de definio ou iniciao, garantindo que os objetivos do projeto esto de acordo e entendido por todos os stakeholders e determinando o escopo e nvel de detalhe requerido para o processo de risco, guiado pela condio de risco e a importncia estratgica do projeto; Aps a definio da identificao do risco, usando tcnicas tais como brainstorms, workshops, checklists, prompt lists, entrevistas, questionrios, etc. Uma variedade de tcnicas podem ser utilizadas para certificar que tantos riscos quantos possveis so identificados. Uma ateno necessria para distinguir riscos dos assuntos relacionados ao risco (por exemplo: problemas, fluxo, causas, efeitos, etc.). A identificao de risco deveria tambm enderear ameaas e oportunidades, desde que ambos estejam includos na definio de um risco como: Qualquer incerteza que, se isso acontecer, afetar a execuo de um ou mais objetivos do projeto. Durante essa fase, o registro preliminar do risco produzido, com mais detalhes adicionados assim que o processo continua; A significncia dos riscos identificados necessita ser avaliada, priorizando os riscos-chave para futura ateno e ao. A avaliao pode ser qualitativa (descrevendo caractersticas de cada risco em detalhes suficiente para permitir que eles sejam entendidos) ou quantitativa (usando modelos matemticos para simular o efeito do risco nas sadas/ resultados do projeto). Os mtodos qualitativos incluem fazer planilhas de riscos numa grade de duas dimenses mostrando a probabilidade e impacto (a matrix P-I) permitindo que o risco seja priorizado e usado para a estrutura de decomposio de risco (Risk Breakdown S tructure RBS para agrupar os riscos por ) tipo/origem; A seguir vem o planejamento de resposta, quando a estratgia e as aes so determinadas para negociar com o risco de modo que fique apropriado, executvel e a preo acessvel. Cada uma das aes deveria ser acordada com os stakeholders e alocado um responsvel, para ento sua efetividade ser avaliada. As respostas s ameaas seriam: impedir, transferir ou reduzir. Englobamse como respostas s oportunidades: explorar, compartilhar ou desenvolver. Os riscos residuais deveriam ser aceitos prontamente com um acompanhamento apropriado pelo uso dos planos de contingncia e retroagir; O planejamento deve liderar a ao, isso torna importante implementar um plano de aes, monitorar a efetividade e relatrio de resultados para os stakeholders. Durante esta fase de implementao, o risco est exposto a uma constante atualizao no projeto, resultado da ao para torn-lo mais suave. A efetividade no processo de risco tambm avaliada quando ajustes necessrios so feitos ao projeto; * Finalmente, qualquer processo de risco deve incluir reviso e atualizao. Risco est sempre mudando no projeto, ento o processo deve ser iterativo, regularmente revisando a exposio do risco, identificando e avaliando novos riscos e garantindo respostas apropriadas. Estes processos de melhores prticas no so naturalmente difceis de implementar, desde que representem um senso comum estruturado na organizao. De fato, esse um modo para definir as melhores prticas: estas no so o que todos atualmente fazem ( meramente prticas genricas), mas o que todos deveriam fazer. As Trs reas para Aperfeioamento Futuro Gerenciamento de projetos
86 De posse dessas informaes, iniciamos o trabalho de assesment (avaliao) operacional, com base no trip organizacional: processos, pessoas e ferramentas. Embora as melhores prticas de gerenciamento de riscos sejam bem-definidas e amplamente utilizadas, existem ainda algumas reas nas quais as prticas de gerenciamento de riscos poderiam ser desenvolvidas para torn-las mais efetivas e maximizar os benefcios possveis para as organizaes que a implementar. O pargrafo seguinte sumariza as trs reas que emergem nos prximos anos e quais merecem ateno como potenciais e vantajosos desenvolvimentos. 1. Integrao do Gerenciamento de Riscos O gerenciamento de riscos freqentemente percebido como uma atividade especfica e realizada por especialistas que usam ferramentas e tcnicas dedicadas. Com a inteno de obter todos os benefcios da implantao do processo de risco para a organizao em geral, importante que o gerenciamento de riscos torne-se completamente integrado ao nvel estratgico e ao operacional. S tal integrao, existe o perigo de que os resultados do gerenciamento de em riscos possam ser utilizados inadequadamente (ou completamente errado) e o projeto e nem a estratgia do negcio tomem julgamento apropriado na avaliao do risco. Uma integrao verdadeira requer algumas mudanas, inclusive o reconhecimento da existncia de incertezas como parte natural dos negcios. Junto a isso, a necessidade de ter interfaces apropriadas com os processos de negcio e ferramentas. Em adio, existe a necessidade de desenvolver um pensamento estratgico baseado em risco dentro da cultura organizacional. A recusa dos riscos comum no nvel de gerncia snior e muito do valor em implementar gerenciamento de riscos pode ser reduzido ou perdido se os tomadores de deciso da organizao no tomarem conta apropriadamente dos riscos. O gerenciamento do risco deve ser visto como parte integral do fazer negcio e deve se tornar construtivo e no-repreensivo, uma caracterstica natural de todo projeto e processo de negcio ao invs de ser conduzido como uma atividade opcional ou adicional. 2. Aumento da Profundidade e Amplitude da Anlise Existe um consenso geral sobre o processo atual de gerenciamento de riscos. Contudo, o desenvolvimento futuro de melhorias se faz necessrio para aumentar sua efetividade, em ambas dimenses: funcionalidade e escopo. Essas duas dimenses de melhoria so responsveis pela profundidade da anlise e amplitude da aplicao. O nvel atual de anlise de risco freqentemente guiado pelas capacidades das ferramentas e tcnicas disponveis. A profundidade da anlise poderia ser melhorada pelo: Desenvolvimento de tcnicas e ferramentas melhores, com aperfeioamento das funcionalidades, melhoria na interface do usurio e melhoria na integrao com outras partes do conjunto de ferramentas; O uso das capacidades dos recursos avanados da Tecnologia da Informao para permitir efetivo gerenciamento do conhecimento e lies aprendidas com a experincia, por exemplo usar inteligncia artificial, sistemas especialistas ou sistemas baseados em conhecimento para permitir novos tipos de anlises; O desenvolvimento de tcnicas existentes de outras disciplinas para aplicao na arena do risco, por exemplo: value management, system dynamics, safety and hazard analysis, financial trading, etc. Gerenciamento de projetos
87 O escopo corrente de gerenciamento de riscos razoavelmente limitado, tendendo a concentrarse em escala de tempo e custo-alvo. Por mais que esses sejam inegavelmente importantes, existem algumas outras reas que deveriam ser cobertas pelo processo do risco. A amplitude da aplicao poderia ser avanada por: A incluso de oportunidades dentro da definio de risco e assegurar que o processo de risco cubra as ameaas e as oportunidades (veja Hillson 2002, 2003); A medio do impacto contra todos os tipos de objetivos, incluindo o desempenho, qualidade, cumplicidade, ambiental ou regulatrio, os objetivos soft (assuntos de fator humano) e os benefcios do negcio; A expanso do escopo do processo de risco inclui um programa de gerenciamento de riscos (endereando riscos para o portflio de projetos, considerando assuntos de inter-relacionamento) e avaliao nos riscos do negcio (tomando conta da orientao do negcio). 3. Aspectos Comportamentais Existe um entendimento comum quanto importncia do comportamento humano no determinante de desempenho (Hillson & Ruth Murray-Webster, 2005). O desenvolvimento futuro no gerenciamento de riscos deve tomar mais conta desse assunto, em ambos gerando dados de entrada para o processo de risco e interpretando sadas. Isso incluiria a rea de heurstica, para identificar regras inconscientes usadas quando fazemos julgamentos sob condies incertas. Deveria tambm considerar atitudes de risco e seus efeitos na validade do processo de risco. Um meio confivel de medio de atitudes de risco necessita ser desenvolvido, para identificar e contabilizar opinio potencial junto aos participantes no processo de risco. O impacto da atitude de risco na percepo de incerteza deveria ser explorado para permitir que os efeitos sejam entendidos e gerenciados. Este tambm permitiria a construo de equipes com maturidade em risco e uma cultura emocional que poderia melhor entender e assim modificar as atitudes de risco, tornando as atitudes de risco categorizadas entre de risco e cautelosa, com a inteno de assegurar que o risco seja assumido com segurana pela organizao. Consideraes Finais A curta histria do gerenciamento de riscos foi de sucesso at hoje, com uma extensa aplicao por muitas indstrias e o desenvolvimento de um core best practices com um forte suporte de infra-estrutura. Embora o gerenciamento de riscos tenha amadurecido dentro de disciplinas reconhecidas, ele ainda no alcanou o seu pico e poder ainda ter desenvolvimento futuro. Existem diversas reas nas quais o progresso do tema demandado. O desenvolvimento nessas reas teria um significante efeito no gerenciamento de riscos, por produzir: Um conjunto de ferramentas e tcnicas de gerenciamento de riscos que estaria plenamente integrado com o projeto e os processos de negcios e com o reconhecimento de que incertezas fazem parte de todos os nveis da organizao (via integrao de gerenciamento de riscos); Melhorias nas anlises dos efeitos dos riscos no projeto e no desempenho do negcio, endereando seu impacto tambm em assuntos mais amplos do que tempo e custo (via aumento da profundidade das anlises e amplitude da aplicao) e cobrindo ameaas e oportunidades;
88 Com a apropriada considerao sendo tomada no fator humano no processo de risco, usando avaliaes de atitudes de risco, contabilizando sistematicamente sua influncia e construindo equipes balanceadas por riscos (via aspectos comportamentais). A ateno para essas reas assegurar que o gerenciamento de riscos continuar a se desenvolver. O gerenciamento de riscos no deve se manter esttico se for para atender seu potencial de contribuio significante para o sucesso do projeto e dos negcios e se for para ele tomar seu lugar como uma indispensvel e efetiva ferramenta de gerenciamento. Sobre os autores Dr. David Hillson PMP, FAPM, FIRM. consultor internacional de gerenciamento de riscos e diretor da Risk Doctor & Partners (www.risk-doctor.com). um conferencista popular e um premiado autor na rea de risco. David reconhecido internacionalmente como um lder-pensador e praticante no campo de risco e tem feito diversas contribuies inovativas para melhorias no gerenciamento de riscos. conhecido por ter criado o RBS Risk Breakdown S tructure e tambm ter promovido a incluso de gerenciamento pr-ativo de oportunidades dentro do processo de risco e recentemente tem trabalhado na aplicao da cultura emocional para as atitudes de risco. David um membro ativo no PMI e fundador e membro do S IG-Risk. Ele recebeu em 2002 o PMI Distinguished Contribution Award por seus trabalhos no desenvolvimento do gerenciamento de riscos nos ltimos anos. Ele Fellow do UK Association for Project Management (APM) e do UK Institute of Risk Management (IRM). Referncia: 1. Association for Project Management (APM) (2004) Project Risk Analysis & Management (PRAM) Guide (second edition). High Wycombe, Bucks UK: APM Publishing 2. Australian/ New Zealand S tandard AS NZS 4360:2004 (2004) Risk management. Homebush NS / W 2140, Australia/Wellington 6001, New Zealand: Standards Australia/Standards New Zealand 3. Hillson, D. A. (2002) Extending the risk process to manage opportunities. Int J Project Management, 20 (3), 235-240 4. Hillson, D. A. (2003) Effective opportunity management for projects: Exploiting positive risk. New York, US: Marcel Dekker 5. Hillson D. A. & Murray-Webster R. 2005. Understanding and managing risk attitude. Aldershot, UK: Gower 6. Institute of Risk Management (IRM) (2002) A Risk Management S tandard. London, UK: AIRMIC/ALARM/IRM 7. Institution of Civil Engineers (ICE) (2002) Risk Analysis & Management for Projects (RAMP) (revised edition). London, UK: Thomas Telford. 8. Newland K. (1997) Benefits of project risk management to an organisation, Int J Project & Business Risk Mgt, 1 (1), 5-14. 9. Project Management Institute (PMI). (2004) A guide to the project management body of knowledge (PMBOK) (Third Edition). Newtown Square, PA, US: Project Management Institute
89 10. UK Office of Government Commerce (OGC) (2002) Management of Risk Guidance for Practitioners. London, UK: The Stationery Office.
3.8 Gerentes de Multiprojetos, quais competncias so necessrias?

Dragan Milosevic, Ph.D - Professor Associado Departamento de Engenharia e Gesto de Tecnologia Universidade Estadual de Portland, Oregon, U.S.A. Peerasit Patanakul, Ph.D - Professor-assistente Faculdade de Gesto em Tecnologia Howe e Instituto de Tecnologia Stevens, New Jersey, U.S.A.
Este estudo prope uma lista integrada de competncias e sua importncia especificamente para gerentes multiprojetos que conduziram mltiplos projetos, simultneos em indstrias de alta velocidade. Adicionalmente s competncias tcnicas, administrativas/ de processo, intrapessoais, interpessoais e estratgicas/ de negcios que podem ajudar gerentes multiprojetos a conduzir cada projeto individualmente, o estudo reconhece que eles deveriam possuir algumas competncias nicas competncias de gesto de mltiplos projetos para serem capazes de coordenar projetos. Baseadas em sua estratgia organizacional e cultural, as organizaes podem selecionar e utilizar contigencialmente esta lista de competncias no processo de contratar gerentes de mltiplos projetos, no desenvolvimento de habilidades, na avaliao de desempenho e no processo de nomeao de gerentes de projeto. No atual ambiente de negcios, projetos so considerados freqentemente como meios de sucesso nos negcios (Frame 1994; Forsberg et al., 2000). E, muitas vezes, estes projetos so implementados em um ambiente de gesto de mltiplos projetos, no qual alguns projetos so gerenciados individualmente como projetos tradicionais, outros como programas e outros ainda como grupos de mltiplos projetos (veja figura 1) (Platje e S eidel 1993; Ireland 1997; Pennypacker e Dye 2002). Usualmente, os projetos tradicionais so suficientemente completos e de natureza estratgica e contam com um gerente de projetos dedicado em tempo integral ao projeto, (Archibald 1975). Por outro lado, um programa conduzido por um gerente de projetos uma famlia de projetos que so fortemente dependentes, compartilham objetivos comuns e resultam numa entrega de produto ou servio exclusiva (PMI 2000). Em muitos casos, alguns projetos, que so menores e possuem uma essncia mais ttica, tendem a ser agrupados de tal forma que um gerente de projetos (gerente de mltiplos projetos) possa conduzi-los simultaneamente (Wysocki et al. 2002). Tipicamente, estes projetos so tradicionais em termos de suas entregas, mas eles so agrupados para alcanar mais eficincia na utilizao dos recursos e melhor gerenciamento (Archibald 1975; Ireland 1997). Este tipo de gesto de projetos , atualmente, de forte interesse por parte de muitas organizaes de vrias indstrias (Fricke e S henhar 2000; Pennypacker e Dye Gerenciamento de projetos
90 2002). Num nvel mais elevado, uma agregao de todos os projetos num ambiente de gesto de mltiplos projetos de uma organizao especfica reconhecida como um portflio de projetos e gerenciada por um assim denominado gerente de portflio (Pennypacker e Dye 2002). Note que at mesmo os termos que empregamos so utilizados com freqncia em outros estudos, eles ainda no esto num padro industrial.
Figura 1. Um ambiente de gesto de mltiplos projetos.
Para conduzir um projeto ao sucesso, um gerente de projetos deve possuir conhecimentos e habilidades em gesto de projetos (Pinto e S levin 1988; Brown e Eisenhardt 1995). Na literatura, diversos pesquisadores centraram seus estudos na competncia de gerentes de projetos (Gaddis 1959; Archibald 1975; Einsiedel 1987; Frame 1999; Pettersen 1991; Thamhain 1991). No entanto, esses estudos foram conduzidos com base em ambientes de gesto de projetos tradicionais, nos quais um gerente de projetos tradicional trata de um projeto por vez. Estudos sobre competncias de gerentes de mltiplos projetos so raros. Ns acreditamos que haja uma diferena nas atividades entre estes dois grupos de gerentes de projetos. Nossa argumentao aqui que gerentes de mltiplos projetos podem necessitar de algumas competncias adicionais que um gerente de projetos tradicional pode prescindir. Para lastrear nossa argumentao, esta pesquisa realizou uma anlise em ambientes de mltiplos projetos de modo a desenvolver uma estrutura e a identificar um jogo de competncias que um gerente de mltiplos projetos deve possuir, especialmente em indstrias de alta velocidade. Com alta velocidade, referimo-nos a indstrias que enfrentem alteraes rpidas e descontnuas na tecnologia e na demanda por parte dos clientes e da concorrncia, de forma que as informaes muitas vezes so insuficientes e imprecisas (Bourgeois e Eisenhardt 1988). No pretendemos, agora, estudar as competncias dos gerentes de programas e gerentes de portflio. Reviso da literatura Base terica Nos idos de 1955, Robert Katz (1955) props um modelo de perfil gerencial que incorporava habilidades tcnicas, humanas e conceituais. Katz tambm declarou que, ao subir na estrutura gerencial, um gerente necessita de mais habilidades humanas e conceituais e menos habilidades tcnicas. S henhar e Thamhain (1994) argumentam que a habilidade conceitual no modelo de Katz muito ampla. Eles propuseram um novo modelo, que inclui o conhecimento e a habilidade gerenciais nas reas tcnica, humana, operacional e estratgica. Eles argumentaram que essas habilidades so significativas para gerentes de engenharia em geral. Na literatura sobre gesto de projetos, os estudos clssicos de Gaddis (1959) e Archibald (1975) enfatizam a importncia do conhecimento tcnico, habilidades administrativas e capacidade de Gerenciamento de projetos
91 liderana dos gerentes de projetos. Mais tarde, os trabalhos de Einsiedel (1987) e Posner (1987) propuseram mais sobre a liderana e habilidades humanas. Thamhain (1991) sugere que gerentes de projetos tenham habilidades de liderana, tcnicas e administrativas, enquanto que Pettersen (1991) prope habilidades referentes soluo de problemas, administrao, superviso e gerenciamento de equipes, relaes interpessoais e algumas outras qualidades pessoais de gerentes de projetos. S imilarmente ao trabalho de Pettersen, Frame (1999) reconhece um jogo de competncias incluindo aquelas baseadas em conhecimentos, com razes sociais e de julgamentos de negcios. Entretanto, estes estudos encontram-se no contexto dos gerentes de projetos tradicional. Reviso crtica e propostas Como argumentado antes, os ambientes atuais de gesto de projetos so considerados como sendo de natureza gerencial de mltiplos projetos, em que podemos encontrar tanto gerentes de mltiplos projetos quanto gerentes de projetos tradicionais; contudo, assumir que gerenciar mltiplos projetos nada mais do que a soma de gerenciar projetos individuais parece estar incorreto. Os motivos so que, um gerente de mltiplos projetos, ao invs de focar nas atividades individuais do projeto ou nos processos de gesto de um projeto tradicional, tem que compartilhar seu foco entre atividades e processos dos mltiplos projetos (Milosevic e Patanakul 2002). Adicionalmente, gerentes de mltiplos projetos devem gerenciar interdependncias e interaes entre projetos (Eskerod 1996). Uma vez que estas atividades de gerenciamento geram algumas diferenas entre gerentes de projetos tradicionais e mltiplos, temos que: Proposta: adicionalmente s competncias dos gerentes de projetos propostas na literatura referente a gerentes de projetos tradicionais, um gerente de mltiplos projetos deveria contar com algumas competncias especficas para liderar um grupo de projetos mltiplo, simultneo. Metodologia da pesquisa Para encaminhar a reviso crtica e a proposta, este estudo possui o seguinte objetivo de pesquisa: identificar as competncias, incluindo seu nvel de importncia, que um gerente de mltiplos projetos deve possuir nos atuais ambientes de gesto de mltiplos projetos. Neste estudo, nosso foco ficou em empresas lderes de mercado de indstrias de alta velocidade que implementaram seus projetos num ambiente de mltiplos projetos (figura 1). Para realizar esta pesquisa, quatro empresas especficas foram selecionadas para participar do estudo (veja tabela 1). Em cada empresa, como partes da metodologia de estudo de caso, fizemos pesquisas semi-estruturadas, revises de documentos de projetos e observaes (Eisenhardt 1989; Yin 1984). Ento foram conduzidas anlises dentro do caso e atravs do caso. Isso incluiu uma comparao da literatura. Nesta fase, obtivemos uma lista preliminar das competncias dos gerentes de projetos. Ao seguir o mtodo Delphi (Linstone e Turoff 1975), esta lista passou por um quadro de especialistas para sua anlise. Resultados e discusses sobre a pesquisa Nesta pesquisa, definimos competncias como o conhecimento, as habilidades e a experincia de um gerente de projetos necessrios para conduzir um projeto (Rowe 1995; Waller 1997). Julgamos que, para gerenciar um grupo de mltiplos projetos, simultneo, um gerente de mltiplos projetos deve possuir dois jogos de competncias: aquelas para gerenciar um projeto individual e aquelas para coordenar os projetos. Neste estudo, categorizamos as competncias para gerenciar um projeto individual em competncias tcnicas, administrativas/ de processo, Gerenciamento de projetos
92 interpessoais, intrapessoais e estratgicas/ de negcios. Um grupo adicional consiste de competncias de gesto de mltiplos projetos que um gerente de mltiplos projetos emprega para coordenar projetos. A seguir, esto listas de competncias de gerentes de mltiplos projetos, incluindo seu nvel de importncia que encontramos a partir deste estudo. Enquanto as listas foram desenvolvidas especialmente a partir de pesquisas de estudos de caso, os nveis de importncia provm de avaliaes de especialistas utilizando as escalas de Likert de 1-7 (sendo 1 no-importante e 7 muito importante). De modo geral, os especialistas indicaram que administrativas/ de processo (6.43) e interpessoais (6.40) so categorias essenciais de competncias que um gerente de mltiplos projetos deve possuir (veja tabela 2). Competncias estratgicas/ de negcios, intrapessoais e de gesto de mltiplos projetos tambm so importantes (5.80, 5.73, e 5.73, respectivamente). Competncias tcnicas so menos importantes (4.09). Estes resultados confirmam a influncia dos estudos de Katz (1955), de S henhar e de Thamhain (1994) que reivindicam que na medida em que cresce o nvel de responsabilidade administrativa dos gerentes, cresce tambm a importncia de suas habilidades humanas em relao s habilidades tcnicas. A seguir, encontram-se discusses detalhadas sobre as cinco competncias mais importantes de cada categoria.
Tabela 1. A descrio de empresas para a pesquisa de estudo de caso.
Tabela 2. O nvel de importncia das competncias dos gerentes de mltiplos projetos (os cinco mais importantes em cada categoria). Gerenciamento de projetos
93 Competncias necessrias para liderar cada projeto individual Competncias administrativas/ de processo incluem os conhecimentos, habilidades e experincias de um gerente de projetos no planejamento, organizao e controle de projetos. Geralmente, espera-se que um gerente de projetos tenha uma base slida de gesto de projetos que ele possa aplicar, de alguma forma, a qualquer tipo de gesto de projetos, como comentou um de nossos entrevistados. Baseado na avaliao dos especialistas, muito importante para um gerente de mltiplos projetos numa indstria de alta velocidade ser competente na monitorao/controle das atividades de projeto (6.67), no gerenciamento dos riscos (6.50), no planejamento e na programao (6.50), no gerenciamento de recursos (6.50) e entendendo os processos de gesto de projetos de uma organizao, (6.00), respectivamente. Competncias interpessoais incluem os conhecimentos, habilidades e experincias de um gerente de projetos na interao com os stakeholders de outros projetos. Estas competncias so essenciais para os gerentes de projetos porque eles freqentemente tm de exercer sua influncia sobre os membros do time de projetos sem ter uma autoridade direta sobre eles. De acordo com nossos especialistas, muito importante para gerentes de mltiplos projetos sobressair-se em liderana (6.67), comunicaes (6.50), gerenciamento de equipes (6.33), soluo de problemas (6.33) e gesto de conflitos (6.17), nessa ordem. Competncias estratgicas/ de negcios incluem os conhecimentos, habilidades e experincias de um gerente de projetos no encaminhamento dos aspectos estratgicos/ negcios em projetos. Ultimamente, a importncia das competncias estratgicas/de negcios na gesto de projetos tem crescido (Frame 1999) como um resultado do crescimento da aceitao dos projetos como veculos bsicos de negcios na comunidade dos negcios (Pennypacker e Dye 2002). Os resultados deste estudo sugerem que gerentes de mltiplos projetos devem ter um senso para negcios (6.33), preocupaes com o cliente (6.00), capacidade de integrao (6.00), pensamento estratgico (5.33) e conscincia para o lucro/custos (5.33). Competncias intrapessoais so a base importante para o desenvolvimento das outras competncias uma vez que elas so qualidades internas ao carter de um gerente de projetos. Neste estudo, os especialistas estabeleceram as competncias intrapessoais que um gerente de mltiplos projetos deve possuir: ser organizado e disciplinado (6.17), responsvel (6.00), pr-ativo e ambicioso (6.00), autocontrolado (5.67) e flexvel (5.17). Embora ns no as discutamos aqui, tambm foram classificadas pelos especialistas as demais competncias dos gerentes de mltiplos projetos tais como de serem empreendedores (4.83), criativos (4.83), visionrios (4.67) e competitivos (4.33). Competncias tcnicas incluem os conhecimentos, habilidades e experincias de um gerente de projetos relativas s facetas tcnicas do produto do projeto. Os especialistas deste estudo acreditam que a competncia simples e mais importante o conhecimento das aplicaes do produto (5.83), que proporciona aos gerentes de mltiplos projetos um entendimento dos conceitos tecnolgicos gerais dos produtos e de suas aplicaes, seguidos pelo conhecimento da tecnologia e tendncias (4.67), conhecimento das ferramentas e tcnicas relacionadas ao desenvolvimento do produto (4.00), conhecimento especfico sobre a tecnologia do produto (3.50) e a habilidade para solucionar problemas tcnicos (2.67). Os baixos ndices das trs ltimas competncias tcnicas parecem estar em sintonia com alguns argumentos na literatura quando se trata de produtos do projeto e tecnologia, os gerentes de projetos no necessitam mais do que um nvel de trabalho de seus conhecimentos. Nas entrevistas, ns ouvimos que mesmo que Gerenciamento de projetos
94 eles (gerentes de multiprojetos) possam no ter a especialidade tcnica que o projeto necessita, eu diria que est em ordem. O time ser suportado por pessoal tcnico. As competncias previamente discutidas so muito importantes para gerenciar cada projeto individual. De fato, todos os gerentes de projetos, gerentes de projetos tradicionais e gerentes de mltiplos projetos devem possuir estas competncias; no entanto, eles podem necessitar delas em intensidades e dinmica diferentes. Por exemplo, no aspecto da liderana, uma vez que os gerentes de mltiplos projetos precisam liderar times mltiplos simultaneamente, seu tempo para cada time limitado e utilizado intermitentemente. Conseqentemente, eles precisam aplicar, em sua capacidade de liderana, um approach de liderana rpida condensada, atuando de maneira descontnua, ou seja, liderar um time, interromper e liderar o outro time com um approach de liderana contingencial. Estes mesmos assuntos apresentam diferentes manifestaes para gerentes de projetos tradicionais, uma vez que eles dispem de todo o seu tempo para liderar somente um time de forma contnua. S imilarmente, a competncia para formar equipes possui diferentes intensidades e dinmica quando empregada por gerentes de projetos tradicionais e por gerentes de mltiplos projetos. Enquanto os primeiros aplicam a formao de equipes de forma diluda e contnua, gerentes de mltiplos projetos recorrem formao de equipes condensadas/ descontnuas. Particularmente, gerentes de projetos tradicionais podem empregar qualquer atividade em seu cronograma de projetos e at mesmo workshops dedicados durante o projeto ( por isso que ns o chamamos de diludo) para forjar sua mensagem de formao de equipe dentro do mesmo time de projetos. Em contraste, gerentes de mltiplos projetos podem ter umas poucas horas por semana para cada um dos times e este o tempo de que eles dispem para condensar toda a arte da formao da equipe. Adicionalmente, aps estas poucas horas, pode ser que eles no vejam mais o time durante toda uma semana. Isso gera uma situao de fora-da-vista = fora-da-mente, aumentando a presso sobre o gerente de mltiplos projetos para condensar com sucesso sua mgica para formar a equipe nestas poucas horas disponveis. Os dois exemplos de competncias de liderana e de formao de equipes indicam claramente que suas intensidades e dinmica so significativamente diferentes dos gerentes de projetos tradicionais para os gerentes de mltiplos projetos quando eles gerenciam projetos individuais (este tambm o caso com outras competncias, por exemplo: planejamento de projetos). Esta diferena onde est o principal risco, pois muitos enxergam esta diferena. Competncias necessrias para a coordenao de projetos Competncias para a gesto de mltiplos projetos: a despeito do fato de que grupos de gerenciamento de mltiplos projetos estiveram por a por um bom tempo (Archibald 1975), houve muito poucas pesquisas empricas sobre isso (Fricke e S henhar 2000), especialmente pesquisas sobre competncias. Neste estudo, o placar do painel de especialistas demonstra que necessrio que os gerentes de mltiplos projetos tenham experincia na gesto de mltiplos projetos (6.17), sejam capazes de gerenciar interdependncias (5.83), multiatividades (5.67), liderem simultaneamente times de mltiplos projetos (5.33) e compreendam processos interprojetos (5.17) em conformidade. O fato de que os especialistas classificaram a experincia na gesto de mltiplos projetos como a competncia mais importante est em sintonia com o estudo de Kuprenas, et al. (2000). Como competncia mais importante na categoria de competncias para a gesto de mltiplos projetos temos a experincia, que neste contexto significa dizer que os gerentes de mltiplos Gerenciamento de projetos
95 projetos j gerenciaram em alguma empresa mltiplos projetos durante algum tempo. Um de nossos entrevistados comentou: em meu caso, aps dois anos de liderana de mltiplos projetos para a empresa, eu estava na situao de sentir-me confortvel em liderar mltiplos projetos. S e voc mudar uma empresa, voc tem que recomear. Isso assegura que gerentes de mltiplos projetos j tenham estabelecido sua credibilidade e rede dentro e fora da organizao. Isso muito importante, pois com quanto mais projetos os gerentes de mltiplos projetos tenham de liderar simultaneamente, mais temas ou interfaces humanas eles devem enfrentar. Gerentes de mltiplos projetos devem ser competentes na gesto de interdependncias, a segunda no placar dos especialistas. S propsito gerenciar interdependncias e interaes eu entre projetos relacionados a marcos, recursos e tecnologia compartilhados. Para fazer isso, os gerentes de mltiplos projetos devem ter perspectivas de sistemas de modo a ver todo o quadro e no se perder nos detalhes, afirmou um entrevistado. O entendimento das interdependncias e das interaes entre projetos tambm suporta os gerentes de mltiplos projetos na soluo de problemas com a compreenso de que qualquer mudana em um projeto pode afetar temas de outros projetos. Alm disso, gerentes de mltiplos projetos devem ter em mente que eles tm de entender como solucionar o problema beneficiando tanto quanto possvel todos os projetos nos quais ele estiver trabalhando. Tambm so importantes as multiatividades nas quais os gerentes de mltiplos projetos estimam sua prpria capacidade de recursos de modo a ajustar as prioridades e mudar os contextos para multiatividades dentre os projetos distintos. As multiatividades representam um desafio significativo porque freqentemente cada projeto possui caractersticas nicas. Com estes desafios, os gerentes de mltiplos projetos iro perder algum tempo durante a mudana de uma atividade para a outra enquanto estiverem restabelecendo o foco. Rubinstein et al. (2001) chamam esta perda de tempo de custos do tempo de troca que pode levar um par de minutos para cada simples troca, conforme um entrevistado. Para serem competentes em multiatividades, os gerentes de projetos devem minimizar os custos dos tempos de troca sendo intensamente organizados, metdicos e focados. Adicionalmente, gerentes de multiprojetos devem reconhecer sua prpria capacidade de recursos. Algumas vezes mais efetivo confiar no time de projetos e delegar algumas atividades do projeto. Gerentes de mltiplos projetos devem ser competentes em liderar simultaneamente diversos times de projetos. Eles precisam selecionar e utilizar diferentes estilos de gesto para cada time: voc precisa ter um estilo que lhe permita trabalhar com um largo espectro de tipos de pessoas diferentes. Voc deve conhecer e adaptar seu estilo a diferentes situaes, de modo a ser efetivo. J que eles possuem tempo restrito para gastar com cada time, gerentes de mltiplos projetos precisam comear com aquilo que denominamos uma formao de equipe condensada, esclarecendo que eles tm que colocar o time coeso e alcanar a confiabilidade do time de forma rpida. Adicionalmente, eles precisam ser especialistas em comunicao, j que a comunicao deve ser muito mais concisa (do que na gesto de projetos tradicionais). Um entrevistado afirmou que voc pode se achar tentando consolidar a comunicao ou sendo mais organizado na comunicao formal, com relatrios sobre a situao e coisas deste tipo ao invs de e-mails informais ou passando nos escritrios das pessoas. complicado ter tempo e um bocado de encontros face-a-face com as pessoas. A quinta competncia mais importante no placar dos especialistas a gesto de processos interprojetos. Essa competncia integra o planejamento/ programao, a monitorao/ controle e o gerenciamento de recursos entre projetos, ajudando os gerentes de mltiplos projetos a Gerenciamento de projetos
96 otimizar sua capacidade prpria de recursos. Eles podem proceder inicialmente deste modo consolidando as entregas dos projetos ou os marcos e gerenciando-os em conjunto. Voc (gerente de mltiplos projetos) realmente tem de ser uma pessoa organizada. Em sua cabea, voc possui entendimento para saber o que prioritrio, de modo que possa fazer uma ordenao de todo o conjunto. Isso o ajudar a gerenciar seu tempo de forma apropriada, de acordo com um dos entrevistados do caso. Implicaes Este estudo examinou as competncias dos gerentes de mltiplos projetos que lideraram grupos de mltiplos projetos. Ele pretende mapear a conscincia na comunidade de gesto de projetos considerando as diferenas entre as competncias dos gerentes de projetos tradicionais das dos gerentes de mltiplos projetos. A grande e singular contribuio deste estudo o jogo de competncias que os gerentes de mltiplos projetos necessitam para a coordenao de projetos. Ns as chamamos de jogo de competncias para a gesto de mltiplos projetos. Alm da lista, este estudo tambm prope o nvel de importncia de cada competncia. Esta lista de competncias e o nvel de sua importncia podem ser utilizados de diversas formas. Eles podem ser empregados como um grupo de critrios para contratar novos gerentes de mltiplos projetos, como um grupo de critrios para avaliao de desempenho, como um grupo de fatores para avaliao de desenvolvimento de competncias e como partes de critrios para nomeao de gerentes de projetos. Para implementar essas listas, as organizaes deveriam empregar um approach contingencial e utilizar estas listas como normas. Concluso Este estudo props uma lista de competncias que gerentes de mltiplos projetos em indstrias de alta velocidade deveriam possuir. Achamos que os gerentes de mltiplos projetos devem possuir competncias administrativas/ de processo, interpessoais, intrapessoais, estratgicas/ de negcios e tcnicas para liderar cada projeto individual e um jogo de competncias para gesto de mltiplos projetos para exercer a coordenao entre projetos. Entretanto, a profundidade que os gerentes de mltiplos projetos devem possuir destas competncias uma escolha da organizao. De muitas formas, nossa lista de competncias parece estar fornecendo uma abordagem para os estudos sobre competncias de gerentes de uma forma geral. (Katz 1955; S henhar e Thamhain 1994) A diferena real em nossas competncias para gesto de mltiplos projetos que so oriundas de estudos com base emprica, o que raro. Mesmo que este jogo de competncias parea ser auto-evidente, ele na verdade no o . De fato, este pode ser um dos motivos que levam crena de que no por que um gerente de projeto teve experincia liderando um projeto individual que pode se tornar um gerente bem-sucedido de mltiplos projetos. Referncias Archibald, R. D. (1975). Managing high-technology programs and projects. New York:: Wiley. Bourgeois, L. J. I., and Eisenhardt, K. M. (1988). S trategic decision process in high velocity environments: Four cases in the microcomputer industry. Management Science, 34, 816-835. Brown, S. L., and Eisenhardt, K. M. (1995). Product development: Past research, present findings, and future directions. Academy of Management Journal, 20, 343-378. Einsiedel, A. A., Jr. (1987). Profile of effective project managers. Project Management Journal, 18(5), 51-53. Gerenciamento de projetos
97 Eisenhardt, K. (1989). Building theories from case study research. Academy of Management Review, 14, 532-550. Eskerod, P. (1996). Meaning and action in a multiple project environment. International Journal of Project Management, 14(2), 61-65. Forsberg, K., Mooz, H., and Cotterman, H. (2000). Visualizing Project Management. (S econd ed.). New York: John Wiley and Sons, Inc. Frame, D. (1994). New Project Management. New York: Jossey-Bass Inc. Frame, J. D. (1999). Building Project Management Competence. S Francisco: Jossey-Bass an Publishers. Fricke, S E., and S . henhar, A. J. (2000). Managing multiple engineering projects in a manufacturing support environment. IEEE Transactions on Engineering Management, 47(2), 258268. Gaddis, P. O. (1959). The project manager. In N. R. Augustine (Ed.), Managing Projects and Programs (pp. 145-162). Boston: Harvard Business School Press. Ireland, L. R. (1997). Managing multiple project in the twenty-first century. In J. S Pennypacker . and L. D. Dye (Eds.), Managing multiple projects (pp. 21-34). New York: Marcel Dekker Inc. Katz, R. L. (1955). Skills of an effective administrator. Harvard Business Review, 33(1), 33-42. Kuprenas, A. J., Jung, C.-L., Fakhouri, S A., and Jreij, G. W. (2000). Project manager workload. assessment of values and influences. Project Management Journal, 31(4), 44-51. Linstone, H. A., and Turoff, M. (1975). The Delphi Method. Reading, Massachusetts: AddisonWesley Publishing Company. Milosevic, D., and Patanakul, P. (2002). S ecrets of successful multiproject managers. Proceedings of Project Management Institute 2002 Annual Seminars and Symposium, San Antonio, Texas. Pennypacker, J. S and Dye, L. D. (2002). Project portfolio management and managing multiple ., projects: Two sides of the same coin? In J. S Pennypacker and L. D. Dye (Eds.), Managing Multiple . Projects (pp. 1-10). New York: Marcel Dekker Inc. Pettersen, N. (1991). S electing project Managers: An integrated list of predictors. Project Management Journal, 22(2), 21-26. Pinto, J. K., and S levin, D. P. (1988). Critical success factors across the project life cycle. Project Management Journal, 19(3), 67-74. Platje, A., and S eidel, H. (1993). Breakthrough in multiproject management: How to escape the vicious circle of planning and control. International Journal of Project Management, 11(4), 209213. PMI. (2000). Project Management Body of Knowledge (PMBOK): Project Management Institute. Posner, B. Z. (1987). What it takes to be a good project manager. Project Management Journal, 18(1), 51-53. Rowe, C. (1995). Clarifying the use of competence and competency model in recruitment, assessment and staff development. Industrial and Commercial Training, 27(11), 12-17. Gerenciamento de projetos
98 Rubinstein, J. S Meyer, D. E., and Evans, J. E. (2001). Executive control of cognitive process in ., task switching. Journal of Experimental Psychology: Human Perception and Performance, 27(4), 763-797. S henhar, A. J., and Thamhain, H. J. (1994). A new mixture of management skills: Meeting the high-technology managerial challenges. Human Systems Management, 13, 27-40. Thamhain, H. J. (1991). Developing project management skills. Project Management Journal, 22(3), 39-45. Waller, R. (1997). A project manager competency model. Paper presented at the Project Management Institute 28th Annual Seminar and Symposium, Chicago, Illinois. Wysocki, R. K., Robert Beck, J., and Crane, D. B. (2002). Extensions to multiple projects. In J. S . Pennypacker and L. D. Dye (Eds.), Managing Multiple Projects (pp. 153-162). New York: Marcel Dekker Inc. Yin, R. (1984). Case study research: Design and methods. (S econd ed.). (Vol. 5). CA: S age Publications. Minicurrculo dos autores: Peerasit Patanakul holds a Ph.D. in S ystems S cience/ Engineering Management from Portland S tate University. Currently, he is an Assistant Professor at the S chool of Technology Management, S tevens Institute of Technology. Peerasits current research interest includes multiple project management, standardized project management, strategic project management, and value-focused project management. Peerasit has engaged in several research projects as team members, for example, Building a strategic system approach to NAS project and program management (a grant from As the Center for Program/ project Management Research, NAS 2004-2005). His works have been A, published in IEEE Transactions on Engineering Management, Journal of High Technology Management Research, Engineering Management Journal, and International Journal of Project Management. Peerasit is a member of IEEE and PMI. Dragan Milosevic holds a BS an MBA, and a PhD in management, all from the University of Belgrade, S , erbia and Montenegro. He has served as a member of the Research Advisory Group for the Project Management Institute. And as a consultant with Rapid innovation, LLC, an executive consulting company, he helps leading companies streamline their project and program management models to ensure profitability. At present, he is an Associate Professor of Engineering Management at Portland S tate University (Oregon). Dragans current research interests focus on multiproject management, and aligning projects with business strategy. Dragan has published in IEEE Transactions on Engineering Management, Technovation, Journal of High Technology management Research, Engineering Management Journal, International Journal of Project Management, and Project Management Journal. His book, Project Management Toolbox published by Wiley, received PMIs the David I. Cleland Project Management Literature Award for 2004. His new book Program Management for the Improved Business Results is coming out by Wiley in the fall 2006. Dragan is a member of IEEE, INFORMS, PDMA, and PMI.
This document was created with Win2PDF available at http://www.win2pdf.com. The unregistered version of Win2PDF is for evaluation or non-commercial use only. This page will not be added after purchasing Win2PDF.

Gerenciamento Projetos

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Gerenciamento Projetos

Transféré par

Droits d'auteur :

Formats disponibles

MBA EXECUTIVO

Aluno(a): ______________________________________________________________ Curso:____________________________________Turma: ______________________

1.2 Carga horria total

1.4 Contedo programtico

Importncia gerenciamento projetos

do Introduo ao gerenciamento de projetos de Caracterizao de projetos de sucesso As restries do projeto

1.6 Critrios de avaliao

1.7 Bibliografia recomendada

1.8 Curriculum resumido do professor

2 Texto para estudo

2.2 O Gerente de projetos

Tabela 1 Habilidades do Gerente de Projetos, segundo Kerzner (1992)

2.3 O ciclo de vida dos projetos

Figura 1 Fases do ciclo de vida do projeto Gerenciamento de projetos

2.4 Processos de gerenciamento de projetos

2.4.1 Grupo de processos de iniciao

2.4.2 Grupo de processos de planejamento

Definio da atividade Seqenciamento de atividades Estimativa de recursos da atividade

Planejamento da qualidade Planejamento de recursos humanos

Planejamento das comunicaes Planejamento do gerenciamento de riscos

2.4.3 Grupo de processos de execuo

Contratar ou mobilizar a equipe do projeto Desenvolver a

Este o processo necessrio para melhorar as competncias e a interao Gerenciamento de projetos

2.4.4 Grupo de processos de monitoramento e controle

Monitorar e controlar o trabalho do projeto

Controle integrado de mudanas

Controle do cronograma Controle de custos

Realizar o controle da qualidade

Gerenciar a equipe do projeto

Gerenciar as partes interessadas

Monitoramento e controle de riscos

2.4.5 Grupo de processos de encerramento

16 O Grupo de processos de encerramento inclui os seguintes processos de gerenciamento de projetos:

2.4.6 Interaes entre processos

Figura 3 - Interao de grupos de processos em um projeto. Fonte: PMI 2004

2.4.7 Mapeamento do processo de gerenciamento de projetos

Gerenciamento de integrao do projeto

Gerenciamento do escopo do projeto

-Planejamento do escopo -Definio do escopo -Criar EAP

-Verificao do escopo -Controle do escopo

Gerenciamento de tempo do projeto

Gerenciamento de custos do projeto

-Estimativa de custos -Oramentao

Gerenciamento da qualidade do projeto

-Realizar a garantia da qualidade

Gerenciamento das comunicaes do projeto Gerenciamento de riscos do projeto

Gerenciamento de aquisies do projeto

-Planejar compras e aquisies -Planejar contrataes

-Solicitar respostas de fornecedores -Selecionar fornecedores

2.5 reas de conhecimento do gerenciamento de projetos

2.5.1 Gerenciamento de integrao do projeto

Monitorar e controlar o trabalho do projeto

Controle integrado de mudanas

2.5.2 Gerenciamento do escopo do projeto

Verificao do escopo Controle do escopo

2.5.3 Gerenciamento de tempo do projeto

2.5.4 Gerenciamento de custos do projeto

2.5.5 Gerenciamento da qualidade do projeto

Realizar o controle da qualidade

2.5.6 Gerenciamento de recursos humanos do projeto

2.5.7 Gerenciamento das comunicaes do projeto

2.5.8 Gerenciamento de riscos do projeto

Planejamento do gerenciamento de riscos Identificao de riscos

Aluno(a): ________________________________________ Curso:Turma: