David Cleland

Gerenciamento de Projetos

Lio 3: Fases do Projeto, Ciclos de Vida e Influncias

Objetivos da Lio: Nesta lio voc vai aprender sobre aspectos chave do gerenciamento de projetos que no pode ser encontrada em outro lugar neste curso. Ao final desse curso, voc dever ser capaz de: Distinguir entre Fases do Projeto e Ciclos de Vida do Projeto Comparar e Contrastar importantes Ciclos de Vidas de Projetos Explicar o conceito de Ciclo de Vidas de sistemas de Gerenciamento e

Modelos de Ciclo de Vidas de Sistemas de Gerenciamento Articular o conceito de organizao matricial Utilizar habilidades-chave de Gerenciamento de Projetos

Termos Chaves Fases do Projeto Ciclo de Vida do Projeto FastTracking Entregveis (deliverables) Marco (Milestones) Organizao Funcional Organizao Projetizada Organizao Matricial

Viso Geral As foras da globalizao e inovao que vem atravessando a nossa economia por mais de 200 anos, esto agora desestabilizando vrios setores da economia. Sejam levadas pelos avanos em computadores, biotecnologia, comunicaes ou outras tecnologias, quedas no custo de logstica, diminuio das barreiras regulatrias, mercado de capitais livres, o aumento da globalizao e a rpida inovao esto alterando profundamente o cenrio comercial. Essas mudanas criam novas possibilidades e levantam novos problemas para os consumidores, empresas e o governo. de interesse geral que o governo entenda esses avanos para conseguir garantir que o mercado continue a ser competitivo para empresas e consumidores.

Projetos e Gerenciamento de Projetos atuam em um ambiente maior que si mesmos. A equipe de Gerenciamento de Projetos precisa entender esse contexto mais amplo gerenciar as atividades do dia-a-dia necessrio para o sucesso de projetos, mas no suficiente. Fases de Projetos e o Ciclo de Vida dos Projetos Conrad Jones (com Booz-Allen 1951-1985) considerado por muitos o pai da teoria do Ciclo de Vida do Produto. Jones foi o gerente de um servio para a S.C. Johnson em 1995, um cliente da Booz-Allen na poca. A companhia queria uma estratgia para desenvolver novos produtos. Jones trabalhou junto de Sam Johnson, o bisneto do fundador da empresa, que foi alocado na sua equipe. Tarde da noite quando os dois jovens estavam trabalhando, Jones ponderou sobre a questo de desenvolvimento de produtos. Jones imaginou se no existia alguma explicao que conseguiria, de alguma maneira, capturar os progressos que muitas pessoas observavam mas no conseguiram entender. Muitas pessoas comentavam sobre a dificuldade de aumentar a taxa de sucesso dos produtos. Havia confuso e controvrsia sobre P&D, manufatura, vendas e marketing sobre prever a demanda precisamente, margens e cotas. Repentinamente, Jones foi para o quadro negro e desenhou dois eixos e uma linha de tendncia; isso pareceu uma colina ngreme, voltando horizontal no plat. Isso, Jones falou para Johnson excitadamente, era o que acontecia com os produtos ao longo do tempo. Seus Ciclos de Vida ditavam que eles nasciam, cresciam rapidamente, ganhavam mercado e depois decaiam. A linha dupla, de lucros por fase com volume ao longo do tempo, demonstrava a razo pela qual, novos produtos devem ser introduzidos continuamente. Empresas no poderiam crescer indefinidamente com o mesmo produto! Fases do Projeto fornecem um arcabouo avanado que permite as organizaes definirem, gerenciarem e acompanharem o produto e os processos de informaes enquanto os produtos so transformados de conceitos abstratos em realidade. Usando as fases de projetos, o conhecimento da organizao gerenciado colaborativamente com uma arquitetura de ponta que promove o gerenciamento com um abrangente passo-a-passo do projeto. Projetos so empreendimentos nicos, por isso eles possuem um grau de incerteza. Organizaes que realizam projetos vo normalmente dividir cada projeto em diversas fases de projeto para permitir um melhor controle gerencial e a conexo correta com outras operaes em andamento da empresa.

Caractersticas das Fases do Projeto Cada fase do projeto delimitada pela entrega de um ou mais entregveis. Um entregvel tangvel, um produto verificvel como um estudo de investimento, um desenho detalhado, ou um prottipo em trabalho. Os entregveis, desta forma as fases, so partes de uma seqncia lgica geral elaborada para garantir a definio

devida do produto do projeto. Cada fase do projeto includo, normalmente, um grupo de atividades desenvolvidas para estabelecer o nvel desejado de controle gerencial. A maioria desses itens esta relacionado com os entregveis da primeira fase e as fases possuem tipicamente o nome desses itens: requisies, desenho, elaborao, texto, reteno e outras como apropriado. O grupo de fases do projeto conhecido como o ciclo de vida dos projetos. Caractersticas do Ciclo de Vida do Projeto Os Ciclos de Vida dos Projetos servem para definir o comeo e o final do projeto. Por exemplo, quando uma organizao identifica uma oportunidade que ela gostaria de aproveitar, ela vai autorizar um estudo de retorno que vai decidir se deve pegar o projeto. A competio para ser o primeiro no mercado causou o encurtamento dos ciclos de vida dos projetos, pelo menos nas indstrias de alta tecnologia. O CEO da Hewlett-Packard observou que o ciclo de vida tpico de um produto hoje de 6 a 12 meses, onde a 5 anos atrs a media do ciclo de vida do produto era de 3 a 5 anos. Ele enfatizou que, para ter sucesso, a HP deve continuadamente investir tecnologias novas e de ponta. A seqncia das fases definida pela maioria dos ciclos de vida do projeto normalmente envolve alguma forma de transferncia como: requisitos para o design, construo de operaes, ou design para a manufatura. Entregveis da fase anterior so normalmente aprovados antes do trabalho comear na fase seguinte. No entanto, algumas vezes a fase seguinte comea antes da aprovao da fase anterior, quando os riscos envolvidos so aceitveis. Essa prtica chamada de FastTracking. Existe uma diferena entre o Ciclo de Vida do Projeto e o Ciclo de Vida do Produto. O projeto que realizado para trazer um novo produto para o mercado apenas uma fase do ciclo de vida do produto. A vida completa de um produto do incio ao fim o ciclo de vida do produto (ex: Windows 95, 97, XP...). O ciclo de vida de um projeto pode durar de algumas semanas ou meses at mais de uma dcada, como no caso da indstria farmacutica, ou grandes projetos de construo como o tnel sob o canal da mancha.

Exemplos de Ciclos de Vida de Projetos

Compras para Defesa Nacional: O Departamento de Defesa Americano descreve uma srie de marcos e fases de aquisio (PMBOK Guide, pg 13). Farmacuticas: A FDA utiliza um ciclo de vida de projeto nico para o desenvolvimento de novos produtos nos EUA (PMBOK Guide, pg 15). Desenvolvimento de Software: a indstria de software usa dois modelos; um modelo em espiral para desenvolvimento de software com quatro ciclos e quatro quadrantes (PMBOK Guide, pg 16) e um modelo linear.

Como visto anteriormente, a maiores das descries dos ciclos de vida de projeto tem uma srie de caractersticas em comum. Eles normalmente usam a abordagem por fases Os nveis de custos e alocao de pessoal so baixos no comeo, maiores

em direo o fim e diminuem rapidamente quando o projeto se aproxima da concluso A capacidade das partes interessadas em influenciar as caractersticas finais

do produto do projeto e o custo final do projeto maior no incio e fica progressivamente menor no curso do projeto Existem critrios de entradas e sadas a serem estabelecidos no incio e no

final de cada fase respectivamente A probabilidade de sucesso do projeto progressivamente maior e o risco

menor ao curso do projeto Influncias Organizacionais Organizaes existem para que o trabalho seja feito, essa sua essncia. De modo geral, qualquer organizao funciona mais eficientemente e eficazmente quando baseada no trabalho a ser feito. Isso pode ser comparado com empresas que se organizam por outros parmetros como histrico, pagamentos ou a personalidade das pessoas envolvidas. Normalmente, os projetos so partes de uma organizao maior do que o projeto em si corporao, agencias do governo, instituies de sade, associaes profissionais e outros. Mesmo quando o projeto a prpria organizao (joint ventures, parcerias), a organizao ou as organizaes que a compem ainda influenciam nos projetos. A estrutura das organizaes que esto realizando o projeto muitas vezes restringe o acesso ou os termos nos quais os recursos podero ser usados no projeto. Estruturas organizacionais podem ser definidas entre os dois extremos, de funcional a projetizada, com uma variedade de estruturas matriciais entre elas. Organizao Funcional A organizao funcional tradicional possui uma hierarquia na qual cada funcionrio tem um superior diretor e onde as funes so sempre as mesmas. As equipes so agrupadas por especialidade, como produo, marketing, engenharia, recursos humanos, desenvolvimento e contabilidade nos nveis mais altos, com habilidades especficas que criam outras sub-divises. O PMBOK Guide demonstra um grfico de uma organizao funcional na pgina 19. No extremo oposto desse tipo de organizao, esto as organizao projetizadas. Organizao Projetizada Na organizao projetizada, os integrantes da equipe so comumente coalocados, ou seja, alocados em mais de uma equipe. A maioria dos recursos de

uma organizao alocada em projetos e os gerentes de projetos tm grande autoridade e independncia sobre eles. Organizaes projetizadas normalmente possuem unidades chamadas de departamentos, mas esses grupos ou reportam diretamente para o gerente do projeto ou oferecem servios de suporte para diversos projetos ao mesmo tempo. A maioria dos projetos e programas governamentais so projetizados. Esse tipo de organizao pode no usar as habilidades dos membros do projeto 100% do tempo. O PMBOK Guidede mostra um grfico de uma organizao projetizada na pg 20. Organizao Matricial As organizaes matriciais so uma mistura das caractersticas das organizaes funcionais com as projetizadas. Uma organizao matricial fraca tem muitas caractersticas da organizao funcional e o papel do gerente de projetos mais o de um coordenador do que o de um gerente mesmo. Uma organizao matricial forte tem muitas caractersticas de uma organizao projetizada como gerentes de projetos em tempo integral com grande autoridade e uma equipe administrativa para projetos em tempo integral. A maioria das organizaes utiliza uma verso desses modelos para atingir seus objetivos estratgicos e preencher sua misso. Atingir um equilbrio entre organizaes projetizadas e funcionais um importante objetivo para as empresas. No importa a estrutura da organizao, o poder do gerente de projetos diretamente relacionado ao nvel de seu superior. Se o escopo do projeto atravessa mais de uma rea funcional de uma empresa, ento o poder dos GPs est no nvel dos gerentes seniores acima dos gerentes destas mesmas reas funcionais que o projeto corta. Sendo assim, se o projeto abrange toda a empresa, o GP deve estar se reportando para os executivos de mais alto escalo que est sendo afetado pelo projeto. Por essa razo, uma matricial forte foi escolhida, pela indstria, como o formato organizacional mais eficiente para projetos. O Gerente de Projetos e a Partes Interessadas devem estruturar a organizao de um projeto de maneira a facilitar o sucesso dos objetivos do projeto. Selecionar o tipo organizacional depende das necessidades do projeto e do estilo gerencial da organizao maior. A extenso da autoridade que a alta direo quer delegar para o gerente de projetos ir ditar o ambiente organizacional. Por exemplo, em uma estrutura projetizada, o gerente de projetos normalmente tem grande autonomia sobre as decises do projeto e tem responsabilidade gerencial sobre a equipe. De outro lado, o gerente de projetos na organizao funcional serve de coordenador e possui pouco poder de tomada de decises formal. Em acrscimo, a maioria das organizaes ter um time central e um time de extenso. Os membros do time central so designados para o projeto como sua responsabilidade primaria e so cobrados pelo sucesso do projeto. Um time central tpico para o desenvolvimento de um produto inclui membros de marketing, engenharia, manufatura, qualidade e suporte tcnico. Os membros do time de extenso so aquelas pessoas que agregam valor para os servios do time central,

mas tem apenas essas responsabilidades marginais. Como exemplo de time de extenso pode-se citar pessoas que so responsveis pelas compras ou servios tcnicos para o time central. da responsabilidade do gerente de projetos criar um time central com membros responsveis por liderar e gerenciar os esforos do time de extenso. Habilidades Gerenciais Chave Existem vrias habilidades gerencias bsicas que so importantes para os projetos ou em certas reas de aplicao. Estas habilidades so o primeiro passo para se desenvolver habilidades de gerenciamento de projetos. Inversamente, o desenvolvimento de fortes habilidades de gerenciamento de projetos a base para se formar bons gerentes. Por essa razo, as empresas esto olhando para os gerentes de projetos como uma fonte de futuros gerentes da empresa como um todo. O PMBOK GUIDE cita as seguintes habilidades chave para gerentes de projetos: Liderar Comunicar Negociar Solucionar Problemas Influenciar a Organizao

Liderar O lder de um projeto uma pessoa que lidera o projeto durante o seu ciclo de vida e alcana os objetivos tcnicos do projeto no prazo e dentro do oramento. Para liderar qualquer esforo organizacional necessrio ter presena e processos. Warren Bennis em Good Managers and Good Leaders, Across the Board, prope uma distino entre liderana e gerencia. Ele diz, O lder faz as coisas certas (eficcia) e o gerente faz a coisa da maneira certa (eficincia). Jeff Tyler no seu livro, True Sayings about Project Management, diz, Voc lidera pessoas, voc gerencia objetos. Comunicar Comunicar-se envolve trocas de informaes. Um pr-requisito bsico para o sucesso de um projeto a comunicao efetiva entre os membros da equipe do projeto e entre as outras partes interessadas. A equipe do projeto deve ser mantida atualizada do status do projeto, das mudanas do ambiente ou do projeto e suas respectivas responsabilidades. Os clientes (como uma parte interessada) esto diretamente interessados no progresso do projeto e deve, contribuir com os processos relacionados definio de requisitos, mudana de gerencias e tomada de decises. A Gerencia Snior est preocupada, com o desempenho do projeto, e deve ser periodicamente informada sobre seu progresso, performance, problemas e riscos. Gerentes funcionais devem estar cientes de quando eles precisam dar suporte ao projeto e qual comprometimento necessrio de seu pessoal.

Negociar Todo mundo negocia o tempo todo, no trabalho, em casa e como um consumidor. Para alguns, isso parece fcil, mas outros vem o processo de negociao como uma fonte de conflito que deve ser evitada sempre que possvel. Negociar, de acordo com o PMBOK GUIDE, envolve discusso com outros para se alcanar um acordo entre todas as partes. Acordos podem ser negociados diretamente ou com um intermedirio; mediao ou arbitragem so dois tipos de negociao com intermedirios. Negociar uma arte praticada por praticamente todos, mas trabalhada por poucos. Existem vrias tcnicas de negociao e vrias oportunidades em um projeto para us-las. Durante o curso de um projeto normal, o gerente de projetos provavelmente vai negociar: Escopo, custo e prazos Responsabilidades Recursos Termos do contrato Mudanas no escopo, oramento e prazo

Melhorando suas habilidades em negociao, o gerente de projetos estar ajudando seus colegas e sua equipe. A capacidade de negociar bem vai poupar tempo, reduzir o estresse e aumentar a produtividade. As mudanas causadas pelas partes interessadas significam que negociar com sucesso no mundo de negcios pode ser crucial para o sucesso do projeto. Solucionar Problemas Problemas sempre ocorrem nos projetos por causa das interfaces com a organizao, as partes interessadas e o sistema. O PMBOK GUIDE identifica solucionar problema como uma combinao entre definio do problema e tomada de deciso. Solucionar problemas est ligado aos problemas que j ocorreram (em oposio ao gerenciamento de riscos que cuida dos problemas em potencial). No sentido de resolver ou prover problemas, o gerente de projetos est sempre tendo que estabelecer prioridades. Existem dois tipos de prioridades que importam para o gerente de projetos para resolver problemas, as prioridades gerais da organizao em questo e as prioridades internas do projeto (utilizao do pessoal, equipamentos, instalaes, etc). O primeiro tipo de prioridade est alm do controle do gerente de projetos, porm ele pode influenci-la. O segundo est dentro do projeto, portanto tambm dentro do controle do gerente de projetos. Em ambos os casos problemas que afetam o projeto necessitam ser identificados, definidos, ter opes para soluo e a melhor deciso possvel. Influenciar a Organizao Influencia pode ser adquirida ou adaptada para melhorar a habilidade do gerente de projetos de ganhar confiana das partes interessadas em vrias situaes do projeto. Focando em tpicos como construir alianas, desenvolver uma base de

influencia, delegar e motivar os outros, aumentar a capacidade de persuaso e habilidade de negociar, o gerente de projetos pode utilizar da diferena entre influencia e poder, e usar a influencia com sucesso na organizao do trabalho todos os dias. Influenciar a organizao necessita tanto de poder quando de poltica. Isso move o gerente de projetos de habilidades tcnicas para habilidades pessoais. Em qualquer projeto, expertise em qualquer das habilidades gerencias chave supracitadas pode ser necessrio. Essas habilidades so bem documentadas e o gerente de projetos prudente mantm proficincia na sua aplicao nos projetos.

Lio 4: Os Processos de um Projeto

Objetivos

Nesta lio voc ir explorar os processos integrados de gerenciamento de projetos. Ao final desta, voc dever poder: Descrever as diferenas entre os processos de projeto e os de produto Explicar como grupo de processos so ligados entre si Descrever interaes entre grupos de processos Articular as relaes dentro dos grupos de processos

Termos Chaves

Grupo de Processos Processos Iniciais Processos de Planejamento Processos de Execuo Processos de Controle Processos de Fechamento Planejamento de Escopo

Definio de Escopo Definio de Atividades Organizao Cronolgica de Atividades Estimativa de Durao de Atividades Desenvolvimento de Cronograma Planejamento de Recursos Estimativa de Custos Oramento de Custos Planejamento de Projetos Planejamento da Qualidade Planejamento Organizacional Contratao de Colaboradores Comunicao Identificao de Riscos Quantificao de Riscos Desenvolvimento de Planos de Ao Planejamento das Aquisies Escopo Qualidade Desenvolvimento de Equipes Distribuio da Informao Solicitao de Compras Seleo de Fornecedores Administrao de Contratos Avaliao de Desempenho Controle de Mudanas Gerais Controle de Mudanas de Escopo Controle de Cronograma Controle de Custos Controle da Qualidade Controle de Planos de Ao para Riscos Fechamento Administrativo

Fechamento do Contrato

Processos de Gerenciamento de Projetos

Qualquer ao dentro de um aspecto do projeto pode afetar outros aspectos deste mesmo projeto. Essas interaes so empricas ou subliminares. Toda mudana de escopo quase sempre afetar o cronograma, os custos, e possivelmente a qualidade do projeto baseado no tamanho da mudana do escopo. Contudo, ela pode ou no afetar a moral da equipe ou a qualidade do produto final. Aes integradas normalmente requerem sacrifcios dentro dos objetivos do projeto. Para lidar com essa natureza integrada dos projetos, eles devem ser gerenciados em termos de processos e suas interaes. O guia PMBOK d uma explicao de processos interligados e proporciona uma base fundamental para entender os processos de gerenciamento de projetos.

Processos do Projeto

Projetos so processos. Eles so compostos de uma srie de atividades ou tarefas com o objetivo de atingir uma meta especfica ou uma srie de objetivos. Esses processos tm como foco o gerenciamento de projetos ou do produto/servio final daquele projeto. De acordo com o guia PMBOK, os processos de gerenciamento de projetos lidam com a descrio e a organizao do trabalho desenvolvido dentro do projeto. Processos de Produto lidam com a criao e as especificaes dos produtos. Estes processos interagem durante o projeto. Processos de gerenciamento de projetos so a estrutura em que o produto ou servio produzido. Processos de produto so aqueles que se referem especificamente definio do produto ou servio. A construo de uma casa ou prdio segue processos de projetos similares. Entretanto, devido a vrias regulamentaes e procedimentos legais, o produto final alcanado utilizando processos de produto diferentes. Por exemplo, o desenvolvimento da armao em ambos os casos um processo do projeto. Mas diferentes construes tm diferentes cmodos e, assim, tem diferentes processos para completar a armao.

Grupos de Processos de Gerenciamento de Projetos

Gerenciamento de projetos composto de cinco grupos de processos conectados pelos resultados que eles produzem. Este resultado ou a sada de um processo vira a entrada para um ou mais outros processos, em que sua sada virar a entrada

para outro, e assim sucessivamente. Os grupos de processos so, segundo o PMBOK: Processos Iniciais Reconhecer que o projeto ou uma etapa deve iniciar e se

comprometer a faz-lo. Processos de Planejamento Redigir e manter um planejamento para

atender s necessidades de negcios para a qual o projeto foi desenvolvido. Processos de Execuo Coordenar pessoas e outros recursos para realizar

o que foi planejado. Processos de Controle Assegurar que os objetivos do projeto so atingidos

atravs do monitoramento e da medio do andamento do projeto, e tomando aes corretivas quando necessrio. Processos de Fechamento Formalizar o termino do projeto ou de uma

etapa, e trazendo ele a um fim de forma oficial e ordenada. Estes grupos de processo podem ser visto como etapas lineares que se sobrepem conforme mostrado no PMBOK, mas so melhores visualizados como processos que interagem entre si dentro de uma etapa. Isso melhor exemplifica como uma mudana dentro de um dos processos pode afetar os outros quatro. A compreenso destes grupos e a relao entre eles imperativo e essencial no gerenciamento de projetos, que esto sempre em constante mudana.

Interaes entre Projetos

Cada grupo de processo conectado pelas entradas e sadas dos outros processos. Entradas podem ser documentos ou aes que devem ser tomadas em projetos utilizando uma ferramenta, tcnica ou procedimento. A utilizao destes resulta em uma sada que, em seguida, vira a entrada de outro processo. Se existir uma falha na identificao de qual ferramenta, tcnica ou procedimento deve ser usado durante uma etapa, essa resultar em uma sada inadequada e afetar negativamente todos os processos subsequentes. esta caracterstica integrativa dos processos que deixam eles to capazes e flexveis, mas tambm os tornam muito volteis. Assim como um maestro de orquestra pode fazer uma bela apresentao musical de uma partitura, utilizando os diferentes instrumentos, um gerente de projetos pode realizar um produto e um servio de sucesso entendendo as interaes entre os processos dos projetos.

Os Processos Iniciais

Os processos inicias consistem na identificao das alternativas dentro de um projeto, a seleo do mesmo, alocao do gerente do projeto e comunicao do incio do projeto aos stakeholders (todas as partes interessadas). Organizaes constantemente se deparam com desafios que exigem uma tomada de deciso ou escolhas difceis. Como cada alternativa requer a utilizao de recursos que geralmente so escassos dentro de uma empresa, fazer uma seleo ou diagnstico correto requer a considerao de alternativas viveis. Avaliar estas alternativas complicado devido, s diversas e, geralmente conflitantes, demandas dos stakeholders aos responsveis pela tomada de deciso. Demandas que competem entre si requerem a identificao de projetos diferentes que podem ser realizados dos quais a organizao deve escolher apenas um antes de comear o trabalho. Decises devem levar em conta as entradas de todos os stakeholders para assegurar que todos contribuiro para o projeto a ser realizado. Um processo eficaz de seleo de projeto deve ser colocado em prtica para assegurar que os processos remetem s estratgias e planos da organizao. Companhias tentam atingir muitas coisas ao mesmo tempo com recursos limitados. Demandas que competem entre si criam dificuldades para a equipe do projeto conseguir a ateno dos responsveis pela gerencia e, tambm, a alocao dos recursos necessrios para o sucesso do projeto. O papel do patrocinador do projeto assegurar decises rpidas, lutar pelos recursos necessrios e resolver conflitos organizacionais e barreiras para o sucesso do projeto. Isso requer que o patrocinador seja membro da equipe de gerenciamento da organizao com a capacidade de tomar decises chaves e influenciar os diferentes grupos de stakeholders quando necessrio. O gerente do projeto tem que ser identificado e alocado o mais cedo possvel e isto sempre deve ser feito antes da execuo do plano do projeto. Experincia industrial tem mostrado que se h um fator determinante para o sucesso do projeto, a seleo de um gerente adequado. Apenas uma pessoa com o conhecimento, experincia e habilidades necessrias deve ser alocada como gerente do projeto pelo patrocinador do mesmo. O incio de um projeto selecionado deve ser documentado formalmente e comunicado adequadamente no Project charter. Este d o gerente de projetos a autoridade sobre os recursos que ele ir utilizar. De acordo com Linn Stuckenbruck, o Project charter deve incluir o propsito do projeto, os objetivos do gerente do projeto, as prioridades do projeto e as limitaes na autoridade, suposies e premissas e no cronograma criado pelo gerente de projetos. O ultimo passo no processo inicial comunicar o Project charter a todas as organizaes afetadas por ele. Isso permite a cooperao inter-organizacional e auxilia uma execuo tranquila, necessria para se atingir o sucesso. Essa comunicao pode ser feita atravs de um memorando ou e-mail do patrocinador a todos que contribuiro ou sofrero impactos do projeto. Por vezes, como no caso

de um programa governamental, a comunicao pode ser feita atravs de um documento contratual entre o patrocinador e o gerente do projeto.

Processos de Planejamento

Os processos de planejamento so, de longe, os mais demorados e detalhados dos grupos de processos de projeto. Ateno a este grupo por parte da equipe do projeto essencial para o sucesso do projeto. De acordo com o PMI, o grupo de processos de planejamento sub-dividido entre os processo bsicos e os processos facilitadores. Os processos bsicos so aqueles que definem o projeto. So eles: Planejamento de escopo para rever e entender o incio ou controle de

entradas, desenvolvimento do escopo, validao do escopo com todos os stakeholders e a criao de um plano de gerenciamento de escopo. Definio de escopo para estabelecer um WBS que abranja cada um dos

entregveis do projeto, e a decomposio do WBS em componentes de trabalho (atividades) e validando o WBS. Definio de atividades para identificar atividades para o cumprimento de

cada entregvel, e a decomposio das atividades em sub-atividades ou tarefas mais fceis de gerenciar. E a criao de um dicionrio de atividades que asseguram que no h nenhuma dvida entre a equipe sobre o que ser feito e o que considerado o final das etapas. Atualizando o WBS com qualquer entregvel que surja como resultado de uma atividade. Sequenciamento de atividades para identificar predecessoras e validar as

mesmas, atualizando a lista de predecessoras com qualquer mudana. Estimativa de durao de atividade para avaliar a capacidade dos recursos

atenderem s expectativas, comparar o atual projeto com dados passados de projetos semelhantes (estimativa por analogia), desenvolver duraes estimadas para cada atividade e atualizar a lista de atividades com as mudanas necessrias. Desenvolvimento do cronograma para calcular o cronograma inicial do

projeto, ajustando o mesmo conforme a necessidade real para a concluso do projeto, organizar o cronograma baseado na sub ou super alocao de recursos, documentar premissas e suposies para referncia futura, desenvolver um plano de gerenciamento do cronograma, e atualizar qualquer necessidade de recursos como resultados dessas aes. Planejamento de recursos para identificar requisito de habilidades para o

projeto, identificar as necessidades de equipamento e material, desenvolver um pool de recursos humanos, e conduzir trocas baseado nas limitaes e o escopo do projeto.

Estimativa de custo revendo custos de projetos passados e dados do

histrico, estimar custos do projeto, ajustar a estimativa levando em considerao questes externas, documentar estes ajustes, e desenvolver um plano de gerenciamento de custos. Realizar o oramento do projeto usando dados histricos e de projetos

passados como base de comparao e fazer ajustes de acordo com razes externas, documentar os resultados e melhorar o plano de gerenciamento de custos. Desenvolvimento do Planejamento do Projeto para rever a validade dos

processos do projeto, desenvolver um plano rascunho para comunicar os elementos essenciais do mesmo (project charter, declarao do escopo, WBS, lista de atividades, cronograma, predecessoras, estimativas de recursos necessrios e custos, avaliao de riscos e qualquer outro fator crtico que possa afetar o projeto). Os processos de facilitao so interaes entre outros processos de

planejamento que so dependentes da natureza do projeto. Estes processos incluem: Planejamento da qualidade para identificar requisitos da qualidade,

monitoramento e controle de procedimentos ligados qualidade do projeto, desenvolvimento de procedimentos operacionais e monitoramento do mesmo, e desenvolvimento do plano de qualidade. Planejamento organizacional para identificar suposies organizacionais e

limitaes, determinar uma estrutura apropriada de projeto, definir o papel e responsabilidades de cada membro da equipe, desenvolver plano de gerenciamento e staff e criar um diagrama para representar esta organizao, documentando qualquer detalhe relacionado a este tpico. Aquisio de staff para avaliar requerimentos de staff, negociar

comprometimento do staff com gerenciamento das funes da equipe, recrutar a equipe do projeto, avaliar e negociar por fora os recursos necessrios, e desenvolver e distribuir os contatos de cada membro entre a equipe. Avaliar as necessidades do projeto em termos de necessidades dos

stakeholders, identificar o melhor meio de comunicao e desenvolver um plano de comunicao. Identificao de riscos, revendo projetos passados em busca de lies

aprendidas, avaliando o projeto atual para encontrar fontes de risco, identificar situaes de riscos, documentar situaes de riscos e entradas para quantificao e melhor entendimento de riscos. Quantificao de riscos para estimar a probabilidade do risco em questo

ocorrer, avaliar o impacto do risco no projeto, e desenvolver uma matriz de aes contra riscos.

Desenvolvimento de um plano de resposta aos riscos para identificar as

aes da organizao a situaes de risco, providenciar entradas de outros processos para amenizar riscos e desenvolver um plano de gerenciamento de riscos. Planejamento de contrato para avaliar as sadas de outros processos de

planejamento que atendem aos requisitos do contrato, escrever definies de trabalho para atender aos requisitos encontrados e desenvolver um plano de gerenciamento de contrato. Plano de aquisies para desenvolver documentos de oferta para dar suporte

aos processos de compra e estabelecer tetos e critrios de oferta a ser considerado.

Processos de Execuo

O grupo de processos de execuo composto pelos projetos que movem em direo ao seu final. Esses processos incluem a execuo do plano do projeto, e dos processos facilitadores. A execuo do plano do projeto inclui a realizao das aes que asseguram que sero tomadas as aes para cumprir com os objetivos identificados no plano de projeto. Isso inclui as atividades do projeto serem desempenhada de acordo com o planejado e mudanas no plano conforme a necessidade. Projetos facilitadores para o grupo de Execuo do Projeto incluem: Verificao do escopo e conduzir a reviso dos resultados alcanados e

recebimento e aceitao formal do escopo do projeto por parte dos stakeholders. Confirmao de qualidade para reviso dos entregveis do projeto antes de

sua implementao, para a antecipao aos desvios na qualidade e resposta a estes, testes dos produtos/servios antes de sua implementao, recebimento de feedback dos stakeholders. Desenvolvimento da equipe e conduo de atividades relacionadas, como

um sistema de reconhecimento de carncias, providenciar treinamento, estabelecer um sistema de mentores e identificar e resolver conflitos entre o pessoal. Distribuio de informao para estabelecer um sistema de distribuio

eficiente, documentar procedimentos de comunicao, avaliar demora e preciso dos meios de comunicao. Solicitao de Contratos para identificar fornecedores em potencial que

atendem aos requisitos do contrato e realizar oramentos com tais fornecedores. Seleo de Fornecedores para avaliar propostas e negociar e elaborar

contratos.

Administrao de Contrato para monitorar desempenho dos fornecedores,

tomar aes corretivas quanto necessrio, autorizar e efetuar mudanas nos contratos e assegurar pagamentos em dia aos fornecedores. Grupo de Processos de Controle

Os processos de controle incluem discrepncias com o planejamento do projeto e depois a tomada de ao para trazer o projeto de volta ao plano inicial. Esse grupo tambm tem processos bsicos e facilitadores. Os processos bsicos incluem: Anlise de desempenho para coletar atualizaes no projeto, identificar

discrepncias com o planejamento inicial, e resumir o desempenho nas diferentes reas problemticas. Controle Geral de mudanas para estabelecer um sistema de mudanas,

comunicar estes controle, e coordenar e autorizar controle de mudanas, documentando as aes tomadas. Os processos facilitadores deste grupo incluem: Controle de Mudana de escopo para assegurar atendimento com os

procedimentos de controle de mudanas, monitorar, avaliar e autorizar mudanas no escopo quando necessrio e documentar os resultados. Controle de cronograma para assegurar o atendimento com os

procedimentos de controle de mudanas de cronograma, avaliar e autorizar mudanas no cronograma quando necessrio e documentar os resultados. Controle de custos para assegurar atendimento ao oramento avaliado,

monitorar e autorizar mudanas no oramento inicial, documentando os resultados. Controle de qualidade atravs do monitoramento do resultado das atividades

conforme o planejado no plano de qualidade e identificar desvios, tomando as aes necessrias para corrigir estas discrepncias, documentando os resultados. Controle de resposta aos riscos para a implementao do gerenciamento de

riscos caso os riscos virem uma realidade, continuar a atualizar e planejar para riscos no identificados no incio e tomar aes, documentando os resultados.

Grupo de Processos de Fechamento

O grupo de processo de fechamento inclui dois processos muito importantes que gerentes tendem a esquecer. Estes so: Fechamento Administrativo para completar e arquivar documentos do

projeto ou da etapa, conduzir e documentar uma reviso ps-projeto e documentar a aceitao final do produto ou servio desenvolvido.

Fechamento de Contratos para avaliar o desempenho de fornecedores e

providenciar aceitao final dependendo de situaes ainda pendentes.

Lio 5: Planejando a Estrutura do Projeto

Objetivos Durante essa lio voc ira explorar os processos necessrios para assegurar que cada um dos elementos do projeto estejam sendo devidamente coordenados. Esses processos interagem uns com os outros. Ao terminar essa lio voc dever:

Abstrair as sadas de outros processos e montar um Plano de Projeto

compreensvel. Seguir o Plano de Projeto executando as atividades nele contidas. Coordenar mudanas em qualquer rea do projeto.

Termos Importantes Sumrio do Projeto Especificaes Declaraes de trabalho Agenda Mestre Guia de Procedimentos Controle de Caixa e Custo Planejamento de Atividades/Rede Previso de Materiais e Equipamentos Matriz de Imapcto ou Matriz de Responsabilidades Plano de Organizao do Projeto Plano de Gerenciamento Planejamento da equipe do Projeto Procedimentos Informativos e de Reviso

Reunies Iniciais Plano de Gerenciamento de Escopo Plano de Gerenciamento de Risco Plano de Gerenciamento de Aquisies Desenvolvimento do Time Distribuio de Informao Garantia de Qualidade Solicitaes Seleo de Fontes Administrao de Contratos Verificao de Escopo

Desenvolvimento de um Plano de Projeto O Plano de Projetos consolida os resultados de outros planejamentos de processos em um documento de comunicao compreensvel que serve para guiar na execuo e no controle de um projeto. Esse processo iterativo. O Plano de Projetos usado para guiar a execuo do projeto, documentar suposies e restries, documentar decises de planejamento, facilitar comunicao entre os steackholders, definir e agendar revises e prover uma base para futuras medidas de progresso e controle do projeto. Todos os resultados do planejamento de um processo so entradas para desenvolver um plano de projeto. Stuckenbruck recomenda a incluso dos seguintes elementos para um plano de projeto: o o o o o o o o o o o Sumrio do Projeto Especificaes Declaraes de trabalho Agenda Mestre Guia de Procedimentos Controle de Caixa e Custo Planejamento de Atividades/Rede Previso de Materiais e Equipamentos Matriz de Impacto ou Matriz de Responsabilidades Plano de Organizao do Projeto Plano de Gerenciamento

o o

Planejamento da equipe do Projeto Procedimentos Informativos e de Reviso

O GUIA do PMBOK recomenda os seguintes elementos como um mnimo: Alvar do Projeto Uma descrio das estratgias do plano de gerenciamento. Declarao de escopo incluindo os entregveis e objetivos do projeto. Estrutura da quebra do trabalho (WBS) a um nvel que possibilite um bom

controle do projeto. Estimativas de custo, agendamento de datas de inicio, distribuio das

responsabilidades no nvel do WBS. Medidas de desempenho para agendamento e custo. Importantes marcos do projeto e suas datas. Equipes necessrias ou equipes chave. Riscos chave incluindo restries e suposies com respostas planejadas

para cada. Plano de gerenciamento subsidirio incluindo plano de gerenciamento de

escopo, plano de gerenciamento de agendamento, etc. Questes em aberto e decises pendentes.

Sero discutidos mais a fundo essas e outras ferramentas, tcnicas e procedimentos nessa e nas prximas lies. Entradas para o desenvolvimento do Plano de Projeto incluindo histrico (banco de dados estimativo, documentao de desempenho de projetos passados, lies aprendidas) devem ser consultadas durando a etapa de planejamento. Essa informao tambm deve estar disponvel durante o desenvolvimento do plano de projetos para ajudar na verificao de hipteses e alternativas. Podem existir organizaes envolvidas no projeto cujos efeitos das polticas formais e informais devem ser consideradas. Restries so fatores que limitam as opes da equipe de gerenciamento. Oramentos pr-definidos so restries que limitam as opes da equipe em relao a escopo, recursos humanos e cronograma. Premissas so eventos que so considerados reais ou verdadeiros para o planejamento do projeto. Se a data em que um pessoa ou processo chave se torna disponvel no conhecida, a equipe pode estipular uma data. Premissas geralmente envolvem certo grau de risco. Premissas tcnicas devem ser limitadas a no mais do que 4 novas e no provadas tecnologias. Ferramentas, tcnicas e procedimentos usados para o Desenvolvimento do Plano do Projeto necessitam algum tipo de metodologia normalmente usada como guia

durante o desenvolvimento do plano de projeto. A metodologia pode ser simples como formulrios ou complexa como series de simulaes. A maioria das metodologias de planejamento de projeto usa hard tools e soft tools. Um software de gerenciamento de projeto, considerado um hard tool, um excelente meio de estruturar o projeto, mas no deve ser usado como muleta assim, excluindo outras ferramentas. Kick off meetings so soft tools importantssimas para o comeo de um projeto. Todo stakeholder traz habilidades e conhecimentos para o projeto que podem ser teis no desenvolvimento do plano de projeto. A equipe deve criar um ambiente em que os stakeholders possam contribuir apropriadamente. Isso cria um sentimento de compra dos stakeholders. O Sistema de Informao de Gerenciamento de Projeto (PMIS) consiste de ferramentas, tcnicas e procedimentos usados para assimilar, integrar e disseminar as sadas para outras etapas de Gerenciamento de Projetos. Esse veiculo de comunicao usado para dar suporte a todos os aspectos do projeto desde o inicio at o encerramento e geralmente incluem ambos sistemas manuais e automticos. O plano de Projeto a sada primaria desse processo. Ele um documento formal aprovado pelo patrocinador e stakeholders usado para se comunicar, gerenciar e controlar a execuo do projeto. O plano de projeto deve ser distribudo como definido no plano de gerenciamento de comunicaes.

Execuo do Plano de Projeto

A execuo do plano de projeto a etapa mais importante para se levar a diante o plano de projeto. A maioria do oramento do projeto ser gasto para a realizao deste processo. Nesta etapa, o gerente de projetos junto com sua equipe deve coordenar e dirigir as mais variadas interfaces tcnicas e organizacionais que existem no projeto. Esta a etapa que mais afetada pela rea de aplicao do projeto no sentido que o produto do mesmo criado nesta etapa.

Os planos de gerenciamento subsidirios (plano de gerenciamento de escopo, plano de gerenciamento de riscos, plano de gerenciamento de requisies, etc.) e as medidas de desempenho so chaves de entrada muito importantes para a execuo do projeto. Aes corretivas sero implementadas para alinhar qualquer desempenho futuro como o plano do projeto. Podem existir organizaes envolvidas no projeto que tero polticas formais e informais que afetaram a execuo do plano do projeto.

A ao corretiva uma sada das variadas etapas de controle que se tornaro entradas para garantir o loop de feedback gerenciamento de projeto efetivo. Ferramentas, tcnicas e procedimentos para a execuo do plano de projeto comeam com as habilidades como liderana, comunicao e negociao. Essas habilidades so essenciais para a execuo do plano de projeto. A equipe deve ter acesso a certas habilidades e conhecimentos sobre o produto final do projeto. Por mais que isso parea obvio devido aos recursos limitados nos mercadas extremamente competitivos de hoje em dia, muitos projetos so executados sem essas habilidades e conhecimentos chaves. Um sistema de autorizao de trabalho um procedimento formal para conceder uma permisso para algum trabalho. Isso assegura que tal trabalho feito na hora certa e a na ordem certa. No confunda isso com controle de mudana cujo objetivo manter que o projeto no saia de seu escopo. O sistema de autorizao geralmente uma autorizao em escrito que permite que um trabalho, atividade ou etapa possa comear. O sistema de autorizao deve equilibrar o custo/benfico, ou seja, controle oferecido e custo do mesmo controle. Por mais que formas verbais de autorizao no gerem custo algum para um projeto, elas no podem comprovar futuramente quem autorizou quem. Reunies de reviso de status outra ferramenta de execuo de um projeto. Essas reunies devem ser agendadas regularmente e servem para passar informaes sobre o projeto. Na maioria dos projetos, essas reunies so feitas em horrios diferentes e em nveis de gerenciamento diferentes. A equipe pode se reunir semanalmente enquanto o cliente e os gerentes seniores podem ter perodos mais longos entre as reunies como um ms ou mesmo meses. Poucas reunies podem acarretar em perda de controle do projeto e muitas reunies podem acarretar perda de qualidade do projeto. O sistema de gerenciamento de informao a essa altura j se tornou um sistema de comunicao e uma ferramenta vital para a execuo do projeto. Mdias de comunicao possuem vantagens e desvantagens dependendo de como elas so usadas. necessrio para assegurar um

Controle de Mudanas Gerais

O Resultado do trabalho conseqncia de atividades realizadas durante o projeto. A informao do resultado dos trabalhos coletada como parte da execuo do projeto e alimentadas na etapa de reportagem de desempenho. Resultados de trabalho incluem entregveis completos e a serem entregues, at que ponto a qualidade foi mantida, quais custos foram necessrios, etc. Pedidos de mudana so geralmente identificados durante a execuo do trabalho. Controle de Mudanas Gerais ser discutido em futuras lies.

Assegurar a Autorizao do Plano de Projeto para Iniciar as Atividades Esse passo representa a transio critica de planejamento para execuo que todos projetos encaram. Muitas suposies sobre disponibilidade de recursos so feitos durante o planejamento do projeto. So essas suposies que agora devem ser colocadas em prtica. Comumente, membros da equipe e outros recursos chaves ainda estaro trabalhando em projetos anteriores ou engajados com alguma responsabilidade funcional quando chegar a hora de executar o projeto. a responsabilidade do Gerente de Projetos junto com os patrocinadores que libere todos recursos de suas responsabilidades para que atividade agendadas possam ser feitas com sucesso. A habilidade de tornar as transies o mais rpido possvel em aes mede a habilidade que a equipe ter em cumprir as atividades agendadas para o projeto. O gerente de projetos tambm responsvel por verificar e prover os recursos necessrios para que sua equipe possa realizar a tarefa e que eles possam coordenar seus trabalhos como uma equipe. Autorizao e a iniciao do projeto necessitam quem o gerente de projetos faam 3 coisas:

Comunicar formalmente o comeo da execuo do projeto para a equipe,

gerentes funcionais e stakeholders chaves. Coordenar junto com gerentes funcionais para liberar sua equipe para que a

mesma possa comear sua tarefas relacionadas ao projeto. Trabalhar individualmente com os membros da equipe para assegurara que

cada um deles esto cientes do cronograma e de suas responsabilidades imediatas.

Realizar Atividades do Projeto como Planejado

Cada membro do projeto tem como responsabilidade realizar suas atividades como planejado. J que os prprios membros criaram o cronograma do projeto, eles devero cumprir o mesmo. Por mais que certas coisas sejam mais difceis de serem feitas do que originalmente planejado, de suma importncia para o sucesso da equipe como um todo que cada membro faa o que disse que ele mesmo faria dentro do cronograma estipulado por ele mesmo.

Tambm muito importante que cada membro trabalhe e coordene, junto com outros membros, suas atividades interdependentes. Quando um membro sentir que no ser capaz de realizar alguma atividade ou ultrapassar algum obstculo, ele deve imediatamente procurar a ajuda de seu gerente de projetos. O gerente de projetos pode pedir ajuda aos patrocinadores para resolver dificuldades ou conflitos.

Realizar as atividades como estipulado no cronograma requer que a equipe realize as seguintes tarefas:

Revise o cronograma e desenvolva um plano de desempenho individual Resistir a tentao de atrasar o cronograma com a esperana de que

poder recuperar o tempo perdido futuramente Trabalhar com gerentes funcionais para resolver conflitos entre atividades

do projeto e responsabilidades funcionais Trabalhar proativamente com outros membros cujo trabalho

interfere com o prosseguimento do seu trabalho ou com o trabalho de outros membros Informar ao Gerente de Projetos qualquer problema que interfira com a

execuo do cronograma ou atividades do projeto e sugerir planos de aes alternativos

Assegurar que as atividades do projeto esto sendo executadas como planejado.

O papel do Gerente de Projetos observar o projeto e assegurar que seus membros completem seus trabalhos como planejado. Por mais que o Gerente de Projetos no tenha uma autoridade direta sobre a equipe, ele responsvel por influenciar as pessoas que realizam o trabalho e ajuda-los a superar qualquer problema que aparecer. Membros da equipe frequentemente fazem suposies incorretas sobre o progresso de outros membros cujo trabalho ele depende e so pegos de surpresa quando no recebem os materiais necessrios.

Outra responsabilidade do Gerente de Projetos assegurar a coordenao entre membros de sua equipe, especialmente aqueles com atividades interdependentes. Assegurar que as atividades sero feitas como planejado requer que o que o Gerente de projetos faa as seguintes tarefas:

Monitorar o desempenho de cada membro de sua equipe para identificar

possveis barreiras que podem estar comprometendo a realizao da atividade dentro do tempo estipulado Trabalhar juntamente com Gerentes Funcionais para resolver a sobrecarga

dos membros de sua equipe Coordenar atividades interdependentes entre membros de sua equipe

Prover treinamento e assistncia para os membros de sua equipe quando

necessrio

Identificar Mudanas Necessrias no Plano de Projeto

Mudanas no plano de projeto so inevitveis durante a execuo de um projeto complexo. Circunstancias constantemente mudam e problemas no antecipados iro surgir e as suposies iniciais feitas durante a etapa de planejamento tero que ser reconsideradas. responsabilidade da equipe e do Gerente de Projetos tentar contornar esses problemas e minimizar as mudanas no plano de projeto. No entanto, responsabilidade dos membros da equipe que alerte o Gerente de Projetos sobre qualquer questo que possa vir a ameaar o cumprimento dos objetivos do projeto.

Esses alertas devem aparecer na etapa de Reportagem de Desempenho discutido na lio 5 , Controlando o Projeto. Identificar mudanas no plano de projeto requer que os membros da equipe e o Gerente de Projetos faam as seguintes tarefas:

Comparar constantemente o progresso do trabalho com o plano de projeto Tentar contornar problemas para minimizar mudana no plano de projeto Alertar imediatamente o Gerente de projetos quando uma questo ameaar

o cumprimento dos objetivos do projeto Tentar identificar as causas e potenciais solues para as mudanas no

plano de projeto Incluir mudanas potenciais no plano de projetos regularmente na

Reportagem de Desempenho

Processos de Facilitao

Os sete processos de facilitao que do suporte e so realizados durante a execuo do plano de projeto so:

1. 2.

Desenvolvimento da Equipe Distribuio de informao

3. 4. 5. 6. 7.

Assegurao de Qualidade Solicitao Seleo de Recursos Administrao de Contrato Verificao de Escopo

Lio 6: Integrando a Estrutura do Projeto

Objetivos da Lio Esta lio foi feita para fornecer uma estrutura bsica ou modelo que ajude a pensar, entender, discutir e gerenciar projetos. Ao termino dessa lio voc dever estar apto a: Identificar e descrever as nove reas de Conhecimento Identificar as suas atuais necessidades de desenvolvimento e forar nos

processos de cada rea

Termos Chave Estrutura de Gerenciamento de Projetos reas de Conhecimento do Gerenciamento de Projetos Iniciao Planejamento de escopo Definio de escopo Verificao de escopo Controle da Mudana de Escopo Definio de Atividade Seqenciamento de Atividades Durao da Atividade Cronograma Controle do Cronograma

Ciclo de Vida Retorno sobre o investimento Fluxo de Caixa Descontado Analise de Payback Identificao de Riscos Quantificao de Riscos Mitigao de Riscos

A Estrutura do Gerenciamento de Projetos A Estrutura de Gerenciamento de Projetos fornece a estrutura bsica para entender o gerenciamento de projetos. Entender essas interaes essencial para entender os corpos de conhecimento e como eles se relacionam com o projeto. As reas de Conhecimento do Gerenciamento de Projetos descrevem o conhecimento e a prtica do gerente de projetos atravs de seus processos. Esses processos foram organizados em 9 (nove) reas de Conhecimento conforme descrito abaixo.

Gerenciamento da Integrao do Projeto Gerenciamento da Integrao do Projeto inclui os processos necessrios para garantir que os diversos elementos do projeto sero devidamente coordenados. Isso envolve fazer trade-offs (escolhas) entre objetivos distintos e alternativas para alcanar ou exceder as necessidades e expectativas das partes interessadas. Enquanto todos os processos de gerenciamento de projetos so integrativos de certa maneira, os processos descritos nesse captulo so primariamente integrativos.

Gerenciamento do Escopo do Projeto Gerenciamento do Escopo do Projeto inclui todos os processos necessrios para garantir que o projeto possua todo o trabalho necessrio, e somente o trabalho necessrio, para que o projeto seja concludo com sucesso. Ele primariamente focado na definio e controle do que est ou no est includo no projeto. A concluso do escopo de um produto medida com referencia nos requisitos enquanto a concluso do escopo de um projeto medida com referencia ao planejamento. Os dois tipos de gerenciamento de escopo devem estar bem integrados para garantir que o trabalho do projeto vai resultar na entrega do produto especificado. Os processos contidos no gerenciamento do escopo so: Iniciao, envolvendo a organizao para comear cada fase do projeto

Planejamento do Escopo, desenvolvendo uma declarao escrita do espoco

como base das futuras decises no projeto Definio de Escopo, subdividindo os maiores entregveis do projeto em

entregveis menores e mais gerenciveis Verificao de Escopo, Formalizando a aceitao do escopo do projeto Controle das mudanas de escopo, controlando as mudanas no escopo do

projeto Gerenciamento do Prazo do Projeto Gerenciamento do Prazo do Projeto inclui os processos necessrios para garantir temporalmente a concluso do projeto. Os sub-processos dentro desse corpo de conhecimento so: Definio das atividades, que consiste na definio de atividades especificas

que devem ser realizadas para produzir os diversos entregveis do projeto Seqenciamento das atividades ou identificao e documentao das

dependncias interativas Durao das atividades ou estimar o nmero de perodos de trabalho que

sero necessrios para completar atividades individuais Desenvolvimento do Cronograma, que significa analisar a sequncia das

atividades, a durao das atividades e as necessidades de recursos para criar o cronograma Em Controle do Cronograma para controlar as mudanas no cronograma do

projeto alguns projetos, especialmente nos pequenos, sequenciamento de

atividades, estimativa da durao das atividades e desenvolvimento do cronograma so to intimamente ligadas que eles podem ser vistos como um nico processo. No entanto, eles so apresentados nessa lio como processos distintos, pois as ferramentas e tcnicas so diferentes para cada. No momento, no existe um consenso dentro da profisso de gerenciamento de projetos sobre as relaes entre atividades e tarefas. De maneira geral, as atividades so vistas como um conjunto de tarefas. Mas alguns vem as tarefas como sendo um conjunto de atividades. Qualquer modo aceitvel, ao menos que a equipe toda use a mesma nomenclatura.

Gerenciamento do Custo do Projeto Gerenciamento do Custo do Projeto inclu os processos necessrios para garantir que o projeto ser concludo dentro do oramento aprovado. Gerenciamento do Custo do Projeto primariamente focado no custo dos recursos necessrios para se completar as atividades do projeto. No entanto, Gerenciamento do Custo do Projeto tambm deveria considerar o efeito das decises no custo de uso do produto final

do projeto. Na maioria das vezes, prever e analisar a possvel performance financeira da produto feito por fora do projeto. Em outros casos, feito como parte do projeto. Quando essas previses e analises so realizadas dentro do projeto, o Gerenciamento do Custo do Projeto ir adicionar novos processos e vrias tcnicas gerais de gerenciamento como Retorno sobre o Investimento, Fluxo de Caixa Descontado, Analise de Payback e outras.

Gerenciamento da Qualidade do Projeto Gerenciamento da Qualidade do Projeto inclu os processos necessrios para garantir que o projeto ir satisfazer as necessidades pelas quais ele foi realizado. Isso inclu todas as atividades da funo gerencial que determina a poltica da qualidade, os objetivos, as responsabilidades e os implementa atravs do planejamento da qualidade, o controle da qualidade e a melhoria da qualidade, tudo isso dentro do sistema da qualidade. A abordagem bsica do gerenciamento da qualidade descrita pelo PMI nessa lio foi feita para ser compatvel com a ISO como as srias de normas ISO 9000 e ISO 10000. Gerenciamento da Qualidade do Projeto deve cobrir tanto o gerenciamento do projeto quanto a qualidade em si do produto final. O insucesso em alcanar os requisitos de qualidade em qualquer desses mbitos pode trazer diversas conseqncias negativas para as partes interessadas.

Gerenciamento dos Recursos Humanos do Projeto Gerenciamento dos Recursos Humanos do Projeto inclu os processos necessrios para ter-se o uso mais eficiente das pessoas envolvidas para o projeto. Isso inclui todas as partes interessadas no projeto. A natureza efmera dos projetos implica que as relaes tanto entre as pessoas quanto com as organizaes sero geralmente temporais e novas. A equipe de gerenciamento do projeto deve ter cuidado em selecionar tcnicas apropriadas para gerir esses relacionamentos dinmicos. O tipo e a quantidade de partes-interessadas iro mudar assim que o projeto evolui de fase para fase do seu ciclo de vida. Como resultado disso, as tcnicas que serviro para uma fase no necessariamente sero as mais adequadas para a outra. A equipe de gerenciamento do projeto deve ter cuidado em usar tcnicas que so apropriadas para as atuais necessidades do projeto. As atividades de administrar os recursos humanos so raramente uma responsabilidade direta da equipe de gerenciamento do projeto. No entanto, a equipe deve estar suficientemente atenta s necessidades administrativas para conseguir trabalhar integrado com o Departamento de Recursos Humanos. Vrias habilidades gerenciais bsicas so diretamente aplicveis para liderar e gerir pessoas nos projetos. Alm disso, o gerente de projetos e a equipe de

gerenciamento do projeto devem estar familiarizados com essas habilidades. Liderar, Comunicar e Negociar so habilidades necessrias para um Gerente de Projetos. Delegar, Motivar, Coaching, Mentoring so habilidades diretamente ligadas com a necessidade de lidar com individuos. Montar uma equipe e lidar com conflitos so habilidades diretamente ligas com a necessidade de lidar com grupos. Controle de performance, de sade e recrutamento, segurana reteno, relaes as de trabalho, do regulamentos esto relacionados funes

Departamento de Recursos Humanos.

Gerenciamento da Comunicao do Projeto Gerenciamento da Comunicao do Projeto inclu os processos necessrios para garantir criao apropriada e em tempo, coleta, disseminao, armazenagem e a disposio das informaes do projeto. Isso fornece a rede de contato entre idias, pessoas e informaes necessrias para o sucesso do projeto. Todos os envolvidos no projeto devem estar preparados para mandar e receber informaes do projeto e devem entender como suas participaes afetam o projeto como um todo. A habilidade gerencial bsica de comunicao no a mesma do gerenciamento da comunicao do projeto. Mesmo sendo relacionada com o gerenciamento da comunicao do projeto, comunicao em geral uma habilidade muito ampla e envolve um volume considervel de conhecimento que no apenas aplicvel no contexto de projeto. Habilidades de comunicao envolvem modelos emissorreceptor, escolha da mdia, escrita, tcnicas de apresentao e tcnicas de conduo de reunies. Gerenciamento da Comunicao do Projeto envolve os processos de Planejar a Comunicao, Distribuio da Informao, Avaliao de Performance e Fechamento Administrativo.

Gerenciamento do Risco do Projeto Gerenciamento do Risco do Projeto inclu os processos referentes com identificar, analisar, quantificar e responder aos riscos do projeto. Isso inclu maximizar os resultados dos eventos positivos e minimizar as conseqncias dos eventos adversos. Existem vrias denominaes diferentes para os processos do risco discutidos nessa lio. Identificao do risco e quantificao do risco so, algumas vezes, tratadas como um processo nico e a combinao desses processos pode ser chamada de anlise de riscos. Desenvolvimento de resposta ao risco algumas vezes chamado de planejamento da resposta ou mitigao de risco. Desenvolvimento da resposta ao risco e controle da resposta ao risco so algumas vezes tratados como um processo nico e a combinao desses processos pode ser chamada de gerenciamento de riscos ou mitigao de riscos.

Gerenciamento da Aquisio do Projeto

Gerenciamento da Aquisio do Projeto inclu os processos necessrios para adquirir bens e servios externos a organizao que est executando o projeto. Para simplificar, bens e servios sero chamados genericamente de produtos. Gerenciamento da Aquisio do Projeto discutida nessa lio sobre a perspectiva do comprador dentro do relacionamento comprador-vendedor. A relao comprador-vendedor pode existir em vrios nveis em um projeto. O vendedor tipicamente gerencia o seu trabalho como um projeto. Nesse caso, o comprador se torna um cliente e, portanto, uma parte interessada chave para o vendedor. A equipe gerencial do projeto do vendedor deve estar atenta a todos os processos do gerenciamento do projeto, no apenas aqueles que se referem as aquisies. Os termos e condies do contrato uma entrada essencial para vrios dos processos do vendedor. O contrato pode at conter vrias entradas (entregveis importantes, marcos, custos) ou ele pode limitar as opes da equipe do projeto (aprovao por parte do comprador nas decises da equipe). Os processos, ferramentas e tcnicas usadas para integrar os processos de gerenciamento de projetos so o foco dessa lio. Gerenciamento da Integrao do Projeto entra em jogo quando o custo estimado necessrio para um plano de contingncia ou quando os riscos associados com alternativas diferentes de equipes devem ser identificados. No entanto, para um projeto ser concludo com sucesso, a integrao deve ocorrer em vrios outros momentos tambm. Gerenciamento da Integrao consiste no desenvolvimento do plano do projeto, na execuo do plano do projeto e no controle geral das mudanas.

Lio 7: Controlando as Mudanas no Projeto

Objetivos da Lio Controlar performance e desenvolver mtricas de analise das variaes so habilidades criticas para o processo de controle assim como para o controle do trabalho, e no para as pessoas que esto realizando as atividades. At o final dessa lio voc deve estar apto para manter seu projeto no curso correto como foi delineado no seu plano de projeto, com as seguintes atividades: Monitorando e Reportando Mudanas Controlando Mudanas do Escopo Controlando Mudanas no Cronograma

Controlando Custos Controlando Qualidade Respondendo aos Riscos

Termos Chave Varincias Mtricas Reportando Performance Desvios de Cronograma Modelo Capacidade-Maturidade

Controle Geral da Mudana Para evitar que mudanas descontroladas dominem o projeto, um sistema de controle geral da mudana deve ser desenvolvido, acordado e implementado com disciplina. No existem muitas evidencias de qualquer projeto que aconteceu exatamente como planejado. Mudanas so inevitveis e devem ser esperadas. Gerentes de Projetos enfrentam uma constante presso para adicionarem mais funes nas especificaes do produto, aumentarem o cronograma devido imprevistos, adicionarem recursos no orados e reduzirem os procedimentos de qualidade. A questo no se as mudanas sero solicitadas, mas, sim, como a equipe do projeto ir responder e administrar essas mudanas. O sistema de controle da mudana deve dar uma direo para qualquer tipo de mudana, sejam elas de escopo, tempo, custo, risco ou qualidade. Ele deve ser acordado entre todos as partes interessadas, incluindo a equipe, o comprador do projeto e os clientes dos servios e produtos do projeto. A tendncia natural da maioria dos projetos que as decises sejam tomadas informalmente, comunicadas verbalmente e que sua atualizao documentada seja ignorada. Essa abordagem informal invariavelmente resulta em confuso, conflito, atrasos no cronograma e clientes insatisfeitos. Portanto, uma responsabilidade primria do gerente de projetos garantir que o sistema de controle das mudanas seja implementado e seguido de maneira disciplinada e formal. Estabelecer um sistema de controle da mudana requer que o gerente de projetos, junto com a participao ativa das principais partes interessadas, sigam as seguintes sete tarefas: 1. Definir o processo para tomada de decises sobre mudanas 2. Definir responsabilidades para diferentes tipos decises sobre mudanas

3. Incluir todos os elementos do plano do projeto, incluindo escopo, prazo, custo, qualidade e risco 4. Desenvolver um procedimento para a atualizao dos documentos mais importantes do projeto para se registrar as mudanas

5.

Revisar o planejamento do risco e identificar quais aes devem ser

mantidas levando em considerao as mudanas ocorridas 6. Ganhar unidade e comprometimento dos membros da equipe do projeto 7. Revisar o sistema de controle das mudanas com o comprador do projeto e as partes interessadas O Controle Geral da Mudana est focado em influenciar os fatores que geram as mudanas para garantir que elas so benficas ao projeto, determinar que uma mudana ocorreu e gerenciar as mudanas no momento de sua ocorrncia. Para fazer isso a equipe do projeto deve manter a integridade da base de avaliao de desempenho, visto que esta base que define a qualidade do projeto. O plano do projeto fornece essa base sob a qual as mudanas sero controladas. Avaliaes de Desempenho, ento, fornecem as informaes sobre o desempenho do projeto. Avaliaes de Desempenho tambm podem alertar a equipe do projeto sobre assuntos que podem vir a causar problemas no futuro. Caso seja necessrio uma mudana do escopo do projeto, deve ser feita uma requisio de mudana. Requisies de mudana podem ser feitas de diversas maneiras. Podendo ser oral ou escrita, direta ou indireta, iniciada internamente ou externamente, necessidade jurdica ou simplesmente opcional. Seja qual for a forma usada, a requisio de mudana deve receber o aval de todas as partes interessadas afetadas pela mudana em questo. Uma falha comum no gerenciamento de projetos complexos tomar uma deciso sobre uma nica rea do controle da mudana sem compreender totalmente o impacto dessa deciso em todas as outras reas. Scope Creep (Deformao de escopo) (algumas vezes chamado de Scope Leap) uma dessas falhas. Essa expanso do escopo do produto acontece quando os clientes ou os desenvolvedores do projeto decidem adicionar novas funes ao produto aps o incio do processo de desenvolvimento sem estimar precisamente o impacto disso em outras reas como cronograma ou esforo necessrio. O resultado que na maioria das vezes o cronograma apertado e isso afeta a qualidade do produto, como quando se reduz o tempo de teste do produto. de responsabilidade do Gerente de Projetos, que possui a melhor compreenso geral do projeto e dos especialistas tcnicos, que possuem o conhecimento tcnico especifico, a garantia de que o impacto total de todas as mudanas foi analisado em todas as reas. Para coordenar as mudanas entre todas as reas de mudanas, o Gerente de Projeto deve executar as seguintes 6 tarefas:

1.

Pedir aos membros da equipe que incluam uma analise dos maiores

impactos das mudanas requisitadas 2. Discutir as requisies de mudanas com o time e ter membros representando o papel de contra a mudana para evitar o consenso sem antes terem debatido a questo completamente 3. Separar tempo para estimar precisamente o impacto da mudana em todas as reas

4.

Realizar um brainstorming e avaliar as diferentes alternativas de

fazer a mudana proposta 5. Discutir as mudanas propostas com as partes interessadas que sero afetadas quando necessrio para entender o pleno impacto da mudana e a sua aceitao 6. Conseguir consenso e comprometimento da equipe para apoiar a mudana Uma vez que a equipe avaliou completamente os possvels impactos da mudana, a ao deve ser propriamente autorizada e os resultados monitorados. Tomar a deciso de agir no a mesma coisa que a ao em si e esse agir no garante que os resultados esperados sero alcanados. Muitas vezes existe uma discrepncia entre a tomada de deciso e a execuo, e muitas vezes essas aes no so monitoradas para se garantir os resultados. Quando os resultados no so positivos ou so diferentes do planejado, outras aes se fazem necessrias. Autorizar e monitorar aes corretivas requer que o gerente de projetos execute as seguintes 5 tarefas: 1. Garantir que a ao proposta autorizada devidamente como definido pelo sistema de controle da mudana 2. Garantir que as pessoas responsveis esto preparadas para realizar a ao corretiva dentro do tempo previsto

3.

Pedir feedback ou uma apresentao formal sobre o status da ao

realizada 4. Avaliar os reais resultados com os pretendidos pela ao 5. Iniciar novas aes corretivas quando necessrio 6. Todas as mudanas no plano do projeto devem estar formalmente registradas na documentao do projeto afetado. Na maioria das vezes, os planos so feitos no inicio do projeto e depois se tornam rapidamente desatualizados e obsoletos. As decises de adicionar, mudar ou deletar a funcionalidade do produto durante o seu desenvolvimento,

normalmente no so refletidas nas especificaes do produto ou no WBS do projeto. Esse tipo de falha acaba mais tarde causando confuso, pois os testes planejados acabam sendo feitos de acordo com especificaes desatualizadas. O plano do projeto e os outros documentos do projeto devem ser vistos como documentos vivos que so continuadamente atualizados e que devem representar o atual status do projeto. Isso fornece uma fonte de informao atualizada para todos os envolvidos e cria um histrico do projeto que pode ser necessrio como referencia no futuro ou at mesmo para aprendizado. Para atualizar os documentos dos projetos os Gerentes de Projetos devem realizar as seguintes 4 tarefas: 1. Designar os responsveis por atualizar os documentos afetados no projeto; 2. Usar um sistema de controle de verses (exemplo: verso 01, verso 02, etc...) para identificar cada atualizao e sua data efetiva; 3. Revisar os documentos que foram atualizados para garantir que esto completos e distribuir, quando necessrio, para as partes interessadas afetadas; 4. Documentar as causas das variaes, as razes das decises, junto com outras lies aprendidas com as mudanas para fazer parte do histrico do projeto como referencia para projetos em andamento e futuros.

Monitorando e Reportando Variaes (Avaliaes de Desempenho) O Gerente de Projeto serve como ponto focal especialmente para as

comunicaes do projeto e as avaliaes de desempenho. Uma avaliao de desempenho padro deve ser especificada por cada contribuinte do projeto e deve incluir sees para avaliar cada elemento do plano do projeto, incluindo escopo, cronograma, custo, qualidade e risco. Em acrscimo, o padro deve ter uma seo para mudanas e aes recomendadas. A freqncia da avaliao pode fazer dependendo da etapa do projeto. Normalmente, os gerentes vo aumentar a freqncia de mensal para 15 em 15 dias para semanal enquanto o projeto se aproxima da sua data final. O Gerente de Projeto deve procurar um equilbrio entre uma avaliao demasiadamente frequente e no ter informao suficiente para entender e administrar o projeto. Relatrios de progresso do projeto normalmente so enviados por e-mail. Em acrscimo, softwares de gerenciamento de projeto tambm permitem relatrio e atualizaes do cronograma do projeto entre a rede de computadores da empresa. A maneira mais eficaz de reportar o progresso do projeto complementada com reunies peridicas nas quais os membros da equipe podem briefar uns aos outros e discutir temas relevantes. Para coletar atualizaes regularmente sobre o desempenho do projeto, o Gerente de Projetos, juntamente com sua equipe, deve realizar as seguintes tarefas:

1. Revisar o plano de comunicao para identificar a freqncia e o formato do acompanhamento 2. Fazer o acompanhamento com todos os membros da equipe para garantir que eles esto reportando o desempenho a tempo

3. 4.

Marcar reunies peridicas da equipe para que eles possam briefar

uns aos outros e discutir o desempenho e outros temas relevantes Fornecer um feedback para os membros da equipe sobre seu

desempenho para demonstrar interesse e o valor da avaliao de desempenho Os membros da equipe devem demonstrar seu progresso individual em relao ao plano do projeto. Variaes, positivas ou negativas, devem ser identificadas, junto com qualquer ao corretiva recomendada. Variaes no plano incluem pontos como escopo, tempo, custo, qualidade e riscos. As reunies da equipe podem ser feitas de maneira eficiente e produtiva focando as discusses nessas mudanas e em suas respectivas aes corretivas. Para identificar essas variaes no plano e as mudanas necessrias, o Gerente de Projeto e sua equipe deve realizar as seguintes 4 tarefas: 1. Reportar o desempenho em relao ao plano inicial 2. Identificar as variaes do plano, tanto negativas quanto positivas 3. Identificar a causa raiz das variaes 4. Definir as aes corretivas recomendadas e as mudanas no plano Embora as reunies da equipe permitam que todos os membros da equipe saibam do desempenho do projeto e seus problemas, o gerente de projetos que tem a melhor compreenso geral de onde o projeto est. de responsabilidade do Gerente de Projetos sintetizar e resumir todos as diferentes informaes para a equipe do projeto, o comprador do projeto e as outras partes interessadas. O resumo do Gerente de Projetos deve ser breve, mas completo. Para resumir o desempenho do projeto, o Gerente de Projetos deve realizar as seguintes 4 tarefas: 1. Agrupar e sintetizar as informaes-chave das avaliaes de desempenho individuais 2. Enfatizar realizaes mais importantes de determinado perodo 3. Identificar assuntos crticos e reas de risco 4. Definir as aes corretivas necessrias, assim como as mudanas no plano

Controlando Mudanas no Escopo

 importante entender as reais causas do pedido de mudana de escopo antes de tomar qualquer deciso. As causas mais freqentes para pedidos de mudanas de escopo so: Erros ou Omisses na Definio dos Requisitos J que difcil para os clientes descreverem tudo querem durante o planejamento do projeto, eles descobrem mais sobre o que eles realmente querem no produto final no decorrer do projeto. Os clientes tm a tendncia de querer mudanas depois que a especificao e desenvolvimento j comearam, resultando em atrasos no cronograma e aumento nos custos. Oportunidades que Agregam Valor Oportunidades no antes vistas de agregar valor ao projeto normalmente aparecem depois do inicio do projeto, como a criao de uma nova tecnologia. Os departamentos de engenharia e de recursos humanos normalmente requisitam esse tipo de mudana, pois so as pessoas que gostam de ter suas novas idias includas nos projetos. A melhor soluo manter o escopo inicial do projeto caso as novas mudanas no tenham valor suficiente para mudar os riscos envolvidos. Presses Competitivas A competio no fica parada durante o projeto e os competidores podem ter surgido com novos produtos com novas funes enquanto o projeto est em andamento. Isso pode forar a equipe do projeto a reavaliar os seus planos e fazer mudanas no design do produto para chegar mais rpido ao mercado. Desvio do Cronograma As trs causas anteriores de mudana no escopo resultam no aumento do escopo do projeto. Uma outra causa de mudanas comum, o desvio do cronograma, fora a equipe a considerar a reduo de escopo de seus projetos. Se aparentemente o cronograma original no pode ser alcanado, mas o cliente no pode aceitar uma data de concluso posterior, ento ou o escopo do projeto deve ser reduzido ou devem ser includos mais recursos para conseguir entreg-lo a tempo. A importncia de se considerar todas as implicaes de mudar o escopo do projeto nunca demais de ser lembrada. Aumentar o escopo, atravs do acrscimo de novas funes, ir adicionar um grau de complexidade no esperado no projeto e, normalmente, ir resultar no desvio do cronograma original. Do outro lado, reduzir o escopo em uma tentativa de recuperar o desvio do cronograma vai normalmente resultar o desapontamento e insatisfao do cliente. Para analisar os pedidos de mudanas de escopo no projeto o Gerente de Projeto deve realizar as seguintes 6 tarefas: 1. Identificar a causa raiz da mudana 2. Estimar os custos de benefcios de se fazer a mudana 3. Identificar as implicaes da mudana de escopo nos outros elementos do plano do projeto, incluindo tempo, custo e qualidade

4. Estimar o risco envolvido em realizar a mudana 5. Estimar o impacto direto para o cliente 6. Discutir as implicaes de se realizar a mudana com as partes interessadas mais importantes, incluindo o comprador do projeto e o cliente Uma vez que a equipe avaliou completamente os impactos do pedido de mudana do escopo, a ao deve ser devidamente autorizada e os resultados monitorados. Recursos devem ser mobilizados para fazer a mudana dentro do tempo necessrio e aes futuras podem ser necessrias caso a mudana no ocorra como planejado. Para autorizar e monitorar as mudanas no escopo, o Gerente de Projeto deve realizar as seguintes 5 tarefas: 1. Garantir que a ao proposta devidamente autorizada como foi definido no Plano de Gerenciamento do Escopo e pelo Sistema de Controle das Mudanas 2. Garantir que as pessoas responsveis esto preparadas para realizar a mudana dentro do prazo

3. 4. 5.

Pedir feedback ou uma avaliao de desempenho formal do status da

mudana Avaliar o real versus o planejado do progresso da mudana

Iniciar aes futuras caso necessrio

Todas as mudanas no escopo do produto, que consequentemente mudam o escopo do projeto, devem ser formalmente refletidas nos documentos afetados do projeto, incluindo requisitos, especificaes, design, a declarao do escopo e a estrutura analtica do projeto. No manter os documentos relacionados ao escopo atualizados pode causar confuso mais a frente do projeto, como no desenvolvimento do plano de testes e na aceitao final do cliente. Os documentos devem ser atualizados continuadamente para refletir as decises mais recentes em relao ao escopo. Isso fornece uma fonte de informaes atual para todos os envolvidos e cria o histrico do projeto, que ser necessrio para referencias futuras e aprendizado. Para atualizar os documentos relacionados ao escopo, o Gerente de Projetos deve realizar as seguintes 4 tarefas: 1. Designar os responsveis por atualizar os documentos afetados 2. Usar um controle de verses numrico (1.0, 2.0, 3.0, etc) consistente para identificar cada atualizao e sua respectiva data

3. Revisar os documentos atualizados para garantir que esto completos e os distribuir, quando necessrio, para as partes interessadas envolvidas

4.

Documentar as causas das mudanas de escopo, as razes das

decises, alem de outras lies aprendidas com a mudana para compor o histrico do projeto para referencias dentro deste projeto e para futuros projeto.

Controlando Mudanas do Cronograma Mudanas no cronograma do projeto podem ter um grande impacto nas outras reas do plano do projeto, incluindo escopo, custo, qualidade, risco, assim como a prpria satisfao do cliente. Esta a razo pela qual to importante gerenciar pedidos de mudanas no cronograma de maneira disciplinada, como descrito no Plano de Gerenciamento de Cronograma e no Sistema de Controle das Mudanas. Para seguir o Plano de Gerenciamento do Cronograma e o Sistema de Controle das Mudanas o Gerente de Projetos deve realizar as seguintes 3 tarefas: 1. Revisar as linhas gerais e os procedimentos para realizar mudanas no cronograma com a equipe do projeto, como definido no Plano de Gerenciamento do Cronograma e no Sistema de Gerenciamento da Mudana 2. Pedir que todas os pedidos de mudanas no cronograma sejam tratados formalmente 3. Revisar o progresso da equipe e do trabalho para garantir que nenhuma mudana de cronograma no autorizada seja feita importante entender as reais causas de pedidos para mudana no cronograma antes de tomar qualquer deciso. A causa mais comum de pedidos de mudanas no cronograma so erros ou omisses durante o planejamento do projeto. J que difcil para a equipe do projeto identificar todas as atividades do projeto e estimar sua durao durante o processo de planejamento, eles descobrem mais sobre o que necessrio para atingir os objetivos do projeto enquanto j esto trabalhando no projeto. Os membros da equipe tm a tendncia de querer revisar seus prazos quando eles so pegos de surpresa com atividades no esperadas e que consomem tempo ou problemas, resultando, assim, em presses para estender o cronograma, reduzir o escopo, adicionar recursos ou diminuir a qualidade do produto final. Outras fontes de pedidos de mudanas de cronograma so: mudanas nos planos do cliente que precisam ser adiantadas, presses internas, competitivas ou dos clientes para aumentar o escopo do projeto e ocorrncia de eventos importantes e no esperados. Para analisar os pedidos de mudanas no cronograma o Gerente de Projeto deve realizar as seguintes 6 tarefas: 1. Identificar a causa raiz do pedido de mudana

2. Estimar os benefcios e custos de realizar a mudana 3. Identificar as implicaes da mudana de cronograma nos outros elementos do plano do projeto, incluindo escopo, custo e qualidade 4. Estimar o risco envolvido em realizar a mudana 5. Estimar o impacto direto para o cliente 6. Discutir as implicaes de se realizar a mudana com as partes interessadas mais importantes, incluindo o comprador do projeto e o cliente

Uma vez que a equipe avaliou completamente os impactos do pedido de mudana do cronograma, a ao deve ser devidamente autorizada e os resultados monitorados. Recursos devem ser mobilizados para fazer a mudana dentro do tempo necessrio e aes futuras podem ser necessrias caso a mudana no ocorra como planejado. Todo esforo deve ser feito no sentido de manter o cronograma dentro de seus limites atravs de aumento da concomitncia, eliminando ou reduzindo atividades que no agregam valor e buscando alternativas criativas para se realizar o trabalho. Para autorizar e monitorar os pedidos de mudanas no cronograma o Gerente de Projetos deve realizar as seguintes 6 tarefas:

1.

Tentar trazer para dentro o cronograma antes de autorizar uma

extenso na data de concluso 2. Garantir que a ao proposta devidamente autorizada como foi definido no Plano de Gerenciamento do Cronograma e pelo Sistema de Controle das Mudanas 3. Garantir que as pessoas responsveis esto preparadas para realizar a mudana dentro do prazo

4. 5. 6.

Pedir feedback ou uma avaliao de desempenho formal do status da

mudana Avaliar o real versus o planejado do progresso da mudana

Iniciar aes futuras caso necessrio

Todas as mudanas no cronograma do projeto devem estar formalmente refletidas nos documentos afetados do projeto, incluindo a EAP, o sequenciamento das atividades, a estimativas de durao das atividades e os planos de gerenciamento dos riscos.

No manter os documentos relacionados ao cronograma atualizados pode causar confuso mais a frente do projeto, como tentar comprar o atual progresso do trabalho com o cronograma para refletir base. Os documentos as decises mais devem ser atualizados em relao ao continuadamente recentes

cronograma. Isso fornece uma fonte de informaes atual para todos os envolvidos e cria o histrico do projeto, que ser necessrio para referencias futuras e aprendizado. Para atualizar os documentos relacionados ao cronograma, o Gerente de Projetos deve realizar as seguintes 4 tarefas: 1. Realizar as mudanas de cronograma e designar os responsveis por atualizar os documentos afetados 2. Usar um controle de verses numrico (1.0, 2.0, 3.0, etc) consistente para identificar cada atualizao e sua respectiva data 3. Revisar os documentos atualizados para garantir que esto completos e os distribuir, quando necessrio, para as partes interessadas envolvidas

4.

Documentar as causas das mudanas de cronograma, as razes das

decises, alem de outras lies aprendidas com a mudana para compor o histrico do projeto para referencias dentro deste projeto e para futuros projeto.

Controlando Custos Mudanas no custo de base do projeto podem ser implicaes significativas para as outras reas do plano do projeto, incluindo escopo, prazo, qualidade e riscos. Esta a razo pela qual to importante gerenciar pedidos de mudanas no custo de base de maneira disciplinada, como descrito no Plano de Gerenciamento de Custos e no Sistema de Controle das Mudanas. Para seguir o Plano de Gerenciamento do Custo e o Sistema de Controle das Mudanas o Gerente de Projetos deve realizar as seguintes 3 tarefas:

1.

Revisar as linhas gerais e os procedimentos para realizar mudanas

no custo com a equipe do projeto, como definido no Plano de Gerenciamento do Custo e no Sistema de Gerenciamento da Mudana 2. Pedir que todas os pedidos de mudanas no custo de base sejam tratados formalmente 3. Revisar o progresso dos gastos para garantir que nenhuma mudana de custos no autorizada seja feita importante entender as reais causas de pedidos para mudana no custo de base antes de tomar qualquer deciso. A causa mais comum de pedidos de mudanas no custo de base so erros ou omisses durante a estimativa de custos do projeto. J que difcil para a equipe do projeto estimar precisamente todos os

recursos necessrios durante o processo de planejamento, eles descobrem mais sobre o que necessrio para atingir os objetivos do projeto enquanto j esto trabalhando no projeto. Os membros da equipe tm a tendncia de querer revisar suas estimativas de custos quando eles so pegos de surpresa com atividades no esperadas e que consomem dinheiro ou problemas, resultando, assim, em presses para estender o cronograma, reduzir o escopo, adicionar recursos ou diminuir a qualidade do produto final. Outras fontes de pedidos de mudanas de custos so: mudanas nos planos do cliente que precisam de mais recursos para adiantar a concluso, presses internas, competitivas ou dos clientes para aumentar o escopo do projeto, presso da empresa para reduzir custos e ocorrncia de eventos importantes e no esperados. Para analisar os pedidos de mudanas no custo de base o Gerente de Projeto deve realizar as seguintes 6 tarefas: 1. Identificar a causa raiz do pedido de mudana 2. Comparar os benefcios de realizar a mudana em relao ao aumento de custo proposto 3. Identificar as implicaes da mudana de custo nos outros elementos do plano do projeto, incluindo tempo, escopo e qualidade 4. Estimar o risco envolvido em realizar a mudana 5. Estimar o impacto direto para o cliente, caso exista 6. Discutir as implicaes de se realizar a mudana com as partes interessadas mais importantes, incluindo o comprador do projeto e o cliente Uma vez que a equipe avaliou completamente os impactos do pedido de mudana do custo, a ao deve ser devidamente autorizada e os resultados monitorados. Todo esforo deve ser feito no sentido de manter o custo de base original do projeto buscando novas abordagens para concluir o trabalho. Para autorizar e monitorar os pedidos de mudanas no custo de base o Gerente de Projetos deve realizar as seguintes 5 tarefas: 1. Tentar conter os custos em outras reas antes de autorizar o aumento do custo de base 2. Garantir que a ao proposta devidamente autorizada como foi definido no Plano de Gerenciamento do Custo e pelo Sistema de Controle das Mudanas 3. Pedir feedback ou uma avaliao de desempenho formal do status da mudana 4. Avaliar o real versus o planejado progresso da mudana

5.

Iniciar aes futuras caso necessrio

Todas as mudanas relacionadas com custos devem ser formalmente refletidas no custo de base e no oramento planejado. No manter os documentos relacionados ao custo atualizados pode causar confuso mais a frente do projeto, como tentar comprar os custos reais do projeto com o que foi orado. Os documentos devem ser atualizados continuadamente para refletir as decises mais recentes em relao aos custos. Isso fornece uma fonte de informaes atual para todos os envolvidos e cria o histrico do projeto, que ser necessrio para referencias futuras e aprendizado. Para atualizar os documentos relacionados aos custos, o Gerente de Projetos deve realizar as seguintes 4 tarefas: 1. Fazer as mudanas no custo de base e os planos de gastos 2. Usar um controle de verses numrico (1.0, 2.0, 3.0, etc) consistente para identificar cada atualizao e sua respectiva data 3. Revisar os documentos atualizados para garantir que esto completos e os distribuir, quando necessrio, para as partes interessadas envolvidas

4.

Documentar as causas das mudanas de custos, as razes das

decises, alem de outros lies aprendidas com a mudana para compor o histrico do projeto para referencias dentro deste projeto e para futuros projeto

Controlando a Qualidade Processos e resultados devem ser constantemente monitorados para garantir que os padres de qualidade esto sendo atingidos pelo Plano de Gerenciamento da Qualidade. O controle de qualidade ideal monitorar os processos nos quais os entregveis so desenvolvidos e identificar desvios na qualidade antes que eles afetem o projeto negativamente. Deste modo, desvios na qualidade ou defeitos podem ser evitados ou minimizados. O segundo melhor mtodo inspecionar ou avaliar os prprios entregveis para identificar desvios ou defeitos. Embora a inspeo no previna a ocorrncia de desvios, ela pode identificar eles rapidamente e possibilitar aes corretivas em tempo. Existem vrias tcnicas populares de controle de qualidade estatstica (pareto, espinha de peixe, etc) usadas na manufatura de produtos que podem ser aplicadas para se identificar desvios nos processos do projeto envolvendo tempo e custos. Para monitorar os processos e seus resultados, o Gerente de Projetos deve realizar as seguintes 6 tarefas: 1. Revisar o Plano de Gerenciamento da Qualidade para identificar as variveis chave do projeto e do produto que devem ser monitoradas 2. Colocar mtodos de monitoramento adequados para todas as variveis chave do projeto e do produto

3.

Monitorar as variveis chave do projeto e do produto de acordo com

os padres de qualidade 4. Identificar qualquer varivel que esteja tendendo para fora do controle ou dos padres 5. Identificar o resultado dos trabalhos e entregveis para garantir que esto de acordo com os padres de qualidade 6. Identificar trabalhos e entregveis que estejam fora dos padres de qualidade Uma vez que os desvios de processo e produtos foram identificados, eles precisam ser analisados para determinar suas causas raiz. importante dar uma grande ateno para se identificar as causas raiz, e no apenas os sintomas, antes de tomar aes corretivas. No caso de um atraso de cronograma, por exemplo, tomar a ao corretiva apropriada vai depender de saber se a causa raiz uma dificuldade tcnica no prevista ou simplesmente uma estimativa de tempo demasiadamente otimista. Diversas ferramentas de qualidade podem ser utilizadas para se identificar as causas razes, desde o diagrama de Pareto (que classifica as causas por frequncia de ocorrncia) at diagrama de causa-efeito (que identifica sistematicamente todas as possveis causas relacionadas com um determinado problema ou defeito). Para analisar os desvios no padro de qualidade, o Gerente de Projetos e sua equipe devem realizar as seguintes 5 tarefas: 1. Obter todas as informaes relevantes sobre o desvio

2.

Organizar as informaes com ferramentas que fornecem melhor

viso e compreenso 3. Organizar uma reunio dos membros da equipe ou outras pessoas envolvidas com o desvio 4. Aplicar as ferramentas de analise mais apropriadas e tcnicas de processo em grupo para identificar as potenciais causas raiz 5. Identificar a causa(s) mais provvel (eis) Aes corretivas apropriadas devem ser decididas e implementadas assim que a causa raiz mais provvel para o desvio na qualidade for identificada. Aes devem ser elaboradas para mitigar os impactos negativos imediatos do desvio e previnir que eles voltem a acontecer. Todas as aes devem ser discutidas com as partes interessadas afetadas, se necessrio, e implementadas de acordo com o Plano de Gerenciamento da Qualidade e os procedimentos que guiam o Controle Geral das Mudanas. Para se tomar aes corretivas, o Gerente de Projetos deve realizar as seguintes tarefas: 1. Identificar potenciais aes para corrigir e prevenir a repetio do desvio

2. Decidir sobre qual ao tem a maior chance de resolver o problema 3. Discutir o plano de ao com as partes interessadas afetadas 4. Designar a responsabilidade da ao para o membro apropriado da equipe 5. Tomar a ao corretiva e monitorar os resultados 6. Tomar novas aes corretivas quando necessrio Todas as aes tomadas em resposta a desvios na qualidade devem ser documentadas como parte do arquivo do projeto. Em acrscimo, o Plano de Gerenciamento da Qualidade deve ser atualizado, junto com o cronograma do projeto e o plano, quando necessrio. Aes corretivas devem ser includas como novas atividades para serem adicionadas ao cronograma do projeto da mesma maneira que as atividades originais foram definidas, sequenciadas e estimadas em durao. Para documentar as aes e atualizar os planos, o Gerente de Projetos deve realizar as seguintes 6 tarefas: 1. Definir as atividades envolvidas com as aes corretivas planejadas

2.

Identificar as dependncias e sequenciamento de atividades da ao

corretiva 3. Estimar a durao das aes corretivas 4. Estimar os acrscimos de recursos e impactos no custo, caso necessrio, das aes corretivas 5. Atualizar o cronograma do projeto e os documentos relacionados com estimativas de todas as aes corretivas 6. Atualizar o Plano de Gerenciamento da Qualidade

Respondendo os Riscos Algumas reas de risco so antevistas durantes o processo de planejamento original, portanto aes preventivas e contingenciais so colocadas no Plano de Gerenciamento do Risco. Aes preventivas so inseridas ao plano de projeto e o cronograma como atividades adicionais. Em oposio as aes contingenciais que so acionadas por eventos reais de risco e so elaboradas para mitigar o impacto negativo sobre os objetivos do projeto assim que o risco se torna real. Para implementar um Plano de Gerenciamento de Riscos, o Gerente de Projetos deve realizar as seguintes 4 tarefas: 1. Identificar a ocorrncia de um evento real de risco que foi planejado no Plano de Gerenciamento de Riscos 2. Decidir se a ao contingencial planejada ainda apropriada e fazer modificaes quando necessrio

3. Comunicar a ocorrncia de um evento de risco e as aes planejadas para as partes interessadas afetadas 4. Tomar a ao contingencial e monitorar os resultados Muitos riscos no podem ser antecipados devido a circunstancias no esperadas, mas devem ser entendidos e planejados assim que so identificados. Novas reas de riscos identificadas devem ser quantificadas e terem uma resposta desenvolvida. Por exemplo, um contratado pode estar tendo problemas em acompanhar o cronograma dos entregveis como foi planejado. Aes poderiam ter sido planejadas para prevenir proativamente o contratado de atrasar as entregas, como fornecer ao contratado recursos extras. Outras aes podem ser planejadas assim que ficar claro que o contratado no ir respeitar o cronograma, como rescindir o contrato e contratar outra pessoa para realizar o trabalho. Para identificar e planejar riscos no antecipados, a equipe do projeto deve realizar as seguintes 4 tarefas: 1. Identificar as novas fontes de riscos para o projeto que no foram planejadas no Plano de Gerenciamento de Riscos original 2. Estimar a probabilidade e o impacto potencial da ocorrncia de um risco para entender sua importncia para o projeto 3. Definir aes preventivas e contingenciais apropriadas para evitar ou mitigar o impacto dessas reas de risco 4. Designar um responsvel para todas as aes relacionadas a riscos As partes interessadas afetadas devem ser imediatamente avisadas sobre novas reas de risco identificadas. Quando o risco no possui grandes chances de ocorrer, a equipe do projeto pode escolher esperar antes de alertar as partes interessadas para coletar mais informaes. Quando os riscos tm uma grande chance de ocorrer ou seu impacto muito grande, as partes interessadas devem estar ativamente envolvidas no planejamento e na tomada de deciso. Para revisar o plano de respostas aos riscos com as partes interessadas, o Gerente de Projetos e sua equipe deve realizar as seguintes 3 tarefas: 1. Determinar o nvel de envolvimento necessrio das partes interessadas na quantificao do risco e no planejamento 2. Informar as partes interessadas de novos riscos identificados e os planos de resposta 3. Envolver as partes interessadas na quantificao e planejamento dos riscos at o ponto necessrio Todas as aes tomadas em resposta a reas de risco devem ser documentadas como parte do arquivo do projeto.

Aes preventivas e contingenciais planejadas para novas reas de risco identificadas so usadas para atualizar o Plano de Gerenciamento de Riscos e mant-lo atualizado. Aes preventivas devem ser includas como novas atividades e inseridas no cronograma do projeto da mesma maneira que as atividades originais foram definidas, seqenciadas e estimadas em durao. Para documentar aes e atualizar os planos, o Gerente de Projetos e sua equipe deve realizar as seguintes 7 tarefas: 1. Documentar todas as aes tomadas como respostas para riscos antecipados, junto com os resultados dessas aes e inseri-las como parte do arquivo do projeto 2. Definir as atividades envolvidas nas aes preventivas planejadas para novos riscos identificados

3.

Identificar as dependncias e sequenciamento das atividades de uma

ao preventiva 4. Estimar a durao das aes preventivas 5. Estimar os recursos adicionais e os impactos no custo, caso necessrio, das aes preventivas 6. Atualizar o cronograma do projeto e os documentos relacionados com todas as aes preventivas estimadas 7. Atualizar o Plano de Gerenciamento de Riscos com as aes preventivas e contingenciais. J que as aes preventivas so tomadas proativamente para previr a ocorrncia de um real evento de risco, elas devem ser executadas de acordo com o cronograma atualizado do projeto assim como qualquer atividade planejada. Para tomar aes preventivas a equipe do projeto deve realizar as seguintes 3 tarefas: 1. Revisar o cronograma atualizado do projeto com a equipe e garantir que os responsveis de cada atividade so definidos para todas as aes preventivas 2. Executar as aes preventivas 3. Reportar o progresso de todas as aes preventivas.

Lesson 8: Evaluating the Project Framework

Lesson Performance (Learning) Objectives

In order to remain profitable organizations require a framework within which specific processes can be optimized to efficiently improve the capability of organizations. A Capability Maturity Model or CMM provides state-of-the-art practices to allow projects to evaluate the maturity of their processes. By the end of this lesson you should be able to: Determine the maturity of your projects processes. Establish goals for project process improvement. Set priorities for immediate project process improvements. Develop a Plan for product or service excellence.

Important Terms Capability Maturity Models Resource Tracking Earned Value Quality Charts

Overview Organizations today operate in an environment of increased competitiveness and change. Successful organizations are those that are effective at change either through creating new markets or meeting new goals for existing products. Yet many companies are ineffective at change and hampered by poor control of their product development operations. Many companies are unable to accurately estimate, control and improve specific product or contract profit margins, product ship dates, or product quality. Companies know that they need to improve, but with inadequate data they often find themselves unable to prioritize problems, leading to excessive improvement initiatives performed in an unfocused manner. Companies are left either spending very little money on improvement because they're unsure how to best allocate the money, or are spending a lot of money very ineffectively on numerous improvement efforts going in 20 different directions. There are several capability maturity models for project management. Each has its advantages and disadvantages. A project management maturity model is being developed by the Project Management Institute and will leverage off of the Carnige Mellon Software Engineering Institutes (SEI) Capability Maturity Model (CMM). For purposes of discussion in this lesson we will orient on the evolution and principles of the SEI-CMM as it relates to your readings. CMMs are public domain tools and are free to use in the process improvement of organizations.

History of Capability Maturity Models In response to a perceived crisis in software development related to escalating software cost and quality problems, the Department of Defense established the Software Engineering Institute (SEI) at Carnegie Mellon University in Pittsburgh, Pennsylvania in the early 1980s. SEI began the development of a process improvement model for software engineering in 1988. In August 1991 the first version of the Capability Maturity Model for Software (SW-CMM) was published by the SEI. Subsequently, the Enterprise Process Improvement Collaboration (EPIC), an industry and government collaborative effort, developed and published the Systems Engineering Capability Maturity Model (SE-CMM), and the International Council on Systems Engineering (INCOSE) developed and published the Systems Engineering Capability Assessment Model (SECAM). Additional CMMs were also developed, including the Software Acquisition CMM, the People CMM, and the Integrated Product Development CMM. Some business domains have also produced their own CMMs. Interest grew in combining the existing systems engineering CMMs into a single systems engineering model. The Electronic Industries Alliance (EIA) in concert with EPIC and INCOSE began an effort to consolidate the two Systems Engineering CMMs. The resulting systems engineering CMM was termed the Systems Engineering Capability Model (SECM) and was assigned the designation EIA/IS-731. Some organizations developed CMMs integrating several disciplines such as the Federal Aviation Administration's integrated Capability Maturity Model (FAA-iCMM). As the SW-CMM Version 2.0 was completing its review process, OSD directed that the CMMI project be undertaken as a collaborative industry, government and SEI effort and that the CMM Version 2.0 be cancelled as a stand-alone CMM and replaced by the software version of the CMMI product suite. Capability Maturity Models (CMMs) are designed to help organizations overcome this problem. They provide an effective and proven method for gradually gaining control of and improving product development processes, a yardstick against which organizations can periodically measure their production process, and data with which to prioritize and manage improvement efforts. CMMs describe both unique product development practices and the common management practices that any organization must perform. These practices are organized into 5 levels, each level describing increasing control and management of the production environment, starting with ad hoc performance and culminating in controlled, structured, continuous improvement. An evaluation of the organization's practices against the model, called

an assessment, determines the level, establishing where the organization stands and which management practices the organization should focus on to see the highest return on investment.

There are over ten years of industry data to show that CMMs are an effective process improvement tool with some data showing as much as a $8 return for every $1 invested in CMM based process improvement. CMMs have been in use for various disciplines with the intent of providing a model of best practices for each of the intended disciplines. Users of these models have demonstrated that product and process improvements are achievable by institutionalizing processes consistent with the practices. In a complex environment, such as development where several of these disciplines are employed, the collective use of individual models has resulted in redundancies, additional complexity, increased costs and at times, discrepancies. To improve the efficiency of model use and increase the return on investment, a CMM Integration project was created to provide a single integrated set of models. Since not all organizations employ every discipline, the project also provides CMMI models for individual disciplines. Since not all processes apply equally to all organizations, the CMMI models are tailorable to an organization's mission and business objectives and criteria for tailoring are provided. A specific CMM for program, project and product management called the Integrated Product Development Capability Maturity Model (IPD-CMM) is being developed. This CMM represents a breakthrough in process improvement tools. It is the first tool of this type to cover the complete product development lifecycle, from developing a business plan to supporting the long-term customer use of a product or phasing the product out of the market. It is also the first tool to characterize the less tangible aspects of successful companies such as leadership and communication. The IPD-CMM was developed by EPIC, a collaboration of industry, academia, and government, and is based on extensive interviews and research. The author team interviewed representatives from a wide variety of successful companies ranging from hospitals to car manufacturers to fighter aircraft manufacturers. The authors then distilled the common set of integrated product development practices that all successful companies performed to develop their product or provide their service. These practices are organized in the model into five sequential levels according to their level of difficulty. The Level 1 practices are those fundamental to product development, and represent the practices essential to being in business. Levels 2 through 5 represent increasing levels of effective leadership and integration. Having these essential practices organized by increasing complexity creates a very powerful tool for companies. Companies can use these levels to measure the effectiveness of their processes by evaluating their activities against the essential practices in the model. They can determine how good their product development practices are, and what they need to improve. The goal of organizations is to be more successful in their core products or services. To do this they must understand their customers, position themselves to their advantage, and know and improve their capabilities.

What is a Capability Maturity Model? A CMM is a tool that describes the basic disciplines and the unique and common management activities any organization must perform. It provides a road map for achieving improved product or service quality and schedule predictability. Finally a CMM is a periodic measurement tool to evaluate the capability of the organizations processes. All CMM tools use the same five levels of maturity: 1. 2. The do-it, Ad Hoc, or no control level. The getting order locally; capturing and sharing project cost, schedule, and

performance data; experimenting and learning from programs level. 3. level. 4. 5. The capturing quantifiable process performance metrics level. Using the captured metrics to improve level. The documenting and sharing the best practices across the organization

Each level is designed to lay the foundation for the next level and to achieve incremental tool. These levels are nearly identical in all CMMs and in some ISO models as well. In the first level the organization is learning to discipline itself and essential elements are performed informally. During the second level the organization begins to control the process chaos and projects begin using defined processes. Work is now planned, managed, and tracked. At the third, and hardest level to achieve, projects are using organizational standardized processes and sharing lessons learned across the organization. In order to achieve this level the processes and practices are well documented for auditing. To achieve the fourth level the organization must manage its processes by capturing process metrics. This establishes a quantitative control measure to provide the baselines for future improvement. Lastly, the fifth level is achieved when the organization takes the captured data and begins a process improvement trend based on quantitative strategic goals. This last level provides the organization with a process of continual improvement. Improvement must happen at all levels. At each level the data that forms the basis of improvement becomes more and more accurate as well as becoming more sophisticated. Data collection and analysis is required to make the transition from one level to the next. The transition from level 1 to level 2 requires the establishment and use of mechanisms to collect project costs and schedule performance (e.g. work breakdown structures, resource tracking, earned value, and quality charts,). The transition from level 2 to level 3 requires the collection and comparison of project performance data and processes used. The organization begins to experiment with various metrics that are reported change and improvement. The key here is the incremental improvement. CMM is a process improvement tool and not a process replacement

and tracked across projects or on selected projects. The organization then establishes business rules and process goals. The transition from level 3 to level 4 requires metrics to be tracked enterprise-wide. A historical database is established and the data in it is tracked over time to provide trends analyses to be performed. The transition from level 4 to level 5 requires the trend analyses to be uses to refine organizational goals and becomes the basis for improvements. CMMs emphasize the collection and using of data at all levels. By doing this the organization will develop a sound product development capability once levels 3 and 4 are reached. The CMM tools require organizations, at all levels, to evaluate their process and document the evaluation to determine if these processes help in meeting the project plan. If not, change the process and document the changes. Use the CMM tool to evaluate the project and determine at what maturity level the project is operating. Focus on improvement efforts that solve problems appropriate for the level that at which the organization is operating.

Lio 9: Iniciao e Planejamento de Escopo

Objetivos da lio:

Durante a realizao de projetos, as organizaes enfrentam constantes mudanas que as foram a optar por um plano de ao alternativo ao planejado. Como cada alternativa aloca quantidades e tipos de recursos diferentes, importante que o projeto s seja iniciado aps a identificao de todas as alternativas possveis e a identificao dos recursos necessrios para realizaremnas. Estudos recentes mostram que o fator que mais causa impacto no cronograma de um projeto a volatilidade de exigncias, ou a quantidade de mudanas ocorridas aps o incio do projeto e seus respectivos impactos na qualidade e tempo do escopo do projeto. Um escopo bem planejado pode reduzir, se no eliminar, essas mudanas. Ao final dessa lio, voc dever saber:

Identificar a viabilidade do projeto; Selecionar o projeto; Identificar o patrocinador do projeto; Selecionar o Gerente do Projeto; Definir o Project charter;

Comunicar a iniciao do Projeto; Definir a descrio dos entregveis; Elaborar um plano de gerenciamento de escopo.

Termos Importantes

Volatilidade de exigncias Retorno sobre Investimento (ROI) rvore de deciso Q-sort Ordenao rpida Scoring models Modelo de scoring Perodo de payback (perodo necessrio para que o lucro iguale o investimento) Escolha forada Programao linear Processo de anlise hierrquica Estrutura de anlise lgica Patrocinador do projeto Stakeholders ou participantes

Iniciao:

Apesar de, as vezes, o Gerente do Projeto no estar envolvido na iniciao do projeto, ele deve estar totalmente ciente das decises tomadas e aes realizadas antes de sua entrada no mesmo. Em toda organizao o projeto no iniciado at que um estudo de viabilidade e esboo seja realizado. Para identificar as alternativas do projeto, o responsvel pelo gerenciamento deve fazer analises baseadas na estratgia da organizao, potencial operacional, retorno sobre o investimento do projeto, espao no mercado futuro do produto ou servio desenvolvido, entre muitos outros fatores. Existem vrias metodologias ou Esses modelos modelos que podem ser utilizados para realizar essa anlise.

normalmente so chamados de modelos de deciso e incluem tcnicas genricas (rvores de deciso, Q-sort, perodo de payback, escolha forada, etc) assim como tcnicas customizveis (programao linear, processo de anlise hierrquica, estrutura de anlise lgica e outros). As aes necessrias para a iniciao de um projeto so:

Identificar as alternativas do projeto;

Selecionar o projeto; Identificar o patrocinador do projeto; Escolher o Gerente do projeto; Definir o Project charter; Comunicar a iniciao do projeto.

Identificar as Alternativas do Projeto

As organizaes so obrigadas a tomar decises difceis e escolher entre diferentes planos de ao constantemente. Para se escolher a melhor alternativa de realizao do projeto, necessrio definir as principais alternativas, j que cada plano de ao requerer o comprometimento de recursos organizacionais especficos. Tais alternativas incluem: Quais melhorias podem ser feitas no produto/servio para alcanar a

satisfao do cliente; Quais novos produtos e servios podem ser oferecidos para se adquirir um

diferencial no mercado;

Quais sistemas organizacionais precisam ser atualizados ou modificados para

melhorar a eficincia e se atualizar com as novas demandas do mercado. Avaliar as alternativas complicado pelo fato de haverem outros fatores envolvidos tambm. Esses fatores, que so impostos pelos stakeholders, podem As demandas conflitantes impostas sobre a ser diversos e at conflitantes.

organizao representam as alternativas de projetos dos quais a organizao deve escolher antes que o projeto seja autorizado e realizado. Para se identificar essas alternativas e demandas, deve-se: Solicitar input dos stakeholders de potenciais projetos relevantes; Criar uma lista com esses potenciais projetos; Revisar a lista com os stakeholders para garantir que ela est completa.

Selecionando o Projeto

Uma seleo de projeto eficaz deve ser feita para que: o projeto a ser realizado esteja alinhado com as estratgias e planos organizacionais, os stakeholders estejam envolvidos e acreditem nas decises finais e as decises sejam tomadas em tempo hbil. A maneira mais eficaz de se optar por um projeto primeiro definir os critrios de seleo do mesmo.

S assim cada alternativa de projeto pode ser julgada objetivamente por representantes dos stakeholders, e a seleo feita. consumidor, impacto na organizao, Os critrios normalmente no mercado, retorno incluem consideraes acerca do: nvel de alinhamento estratgico, impacto no posicionamento financeiro e viabilidade. Para uma melhor visualizao, uma matriz pode ser

construda levando em considerao as alternativas e os critrios de seleo. Cada alternativa pode ser julgada em uma escala de baixo para alto (1=baixo, 2=moderado, 3=alto) e, assim, determina-se a importncia e prioridade do mesmo na organizao. Um dos maiores desafios das organizaes hoje em dia responder com rapidez e eficcia s novas demandas do mercado e as oportunidades limitadas que so oferecidas, tornando seus servios e/ou produtos melhores e mais eficientes. As principais vantagens de entrar em um mercado antes da concorrncia incluem uma alta participao no mercado e possibilidade de gerar lucros. O perodo de gestao para avaliao, autorizao e insero de novos produtos normalmente consomem uma parte significativa da janela aberta pelo mercado. A forma como a organizao aproveita a oportunidade diretamente proporcional ao retorno que ela vai obter. Para selecionar um projeto, preciso: Identificar o critrio de seleo do projeto; Assegurar a aceitao dos critrios por parte dos stakeholders; Criar uma matriz de seleo de projeto; Reunir com stakeholders para avaliar as alternativas de projetos; Calcular a alternativa de projeto que agregar mais valor organizao; Verificar a aceitao por parte dos stakeholders aps a definio da melhor

alternativa.

Identificar o Patrocinador do Projeto

As organizaes frequentemente almejam muitas coisas com recursos limitados. As demandas impostas pelos projetos dificultam a ateno da Gerncia e o comprometimento requerido pelos recursos para que eles sejam realizados com sucesso. As obrigaes do patrocinador do projeto so: garantir a tomada de decises em tempo hbil, preocupar-se e prover os recursos necessrios, e superar conflitos e barreiras organizacionais para a realizao do projeto. Isso requer que o patrocinador faa parte do corpo gerencial da organizao com a habilidade e autoridade para tomar decises chave e influenciar os stakeholders mais importantes. O patrocinador tambm responsvel por selecionar e capacitar o

gerente do projeto. Para se identificar o patrocinador necessrio:

Identificar um membro da diretoria da organizao que mais sofrer

impactos com o produto do projeto; Certificar-se que o candidato tenha obtido sucesso em projetos similares; Verificar com o candidato se ele tem interesse e poder se comprometer ao

projeto; Garantir o aval dos outros membros da Diretoria; Comunicar quem o patrocinador para os principais stakeholders do projeto.

Escolher o Gerente do Projeto

Uma pessoa com o conhecimento, experincia e habilidades necessrias deve ser indicada pelo patrocinador do projeto para exercer a funo de gerente. Estudos mostram que o principal motivo para o sucesso de qualquer projeto a seleo de um gerente adequado para o mesmo. As consideraes mais importantes e que devem ser levadas em conta na hora de selecionar o candidato correto so: Tcnicas de integrao; Habilidade de liderana; Experincia em gerenciamento de projetos; Conhecimento da organizao; A habilidade de obter a cooperao dos stakeholders mais importantes.

O gerente do projeto deve ser identificado e efetivado o mais cedo possvel. Preferivelmente antes que a execuo do planejamento do projeto comece.

Definir o Project Charter

A iniciao do projeto selecionado deve ser formalmente documentada e comunicada atravs do Project Charter. O Project Charter garante ao gerente do projeto a autoridade para aplicar os recursos organizacionais necessrios para que o projeto comece suas atividades. mnimo: As qualificaes necessrias para o gerente do projeto; Objetivos gerenciais especficos do projeto; A prioridade do projeto relativa s iniciativas organizacionais; O nvel de autoridade dado ao gerente do projeto e seus limites; Modelos para o Project charter podem ser elaborados pela organizao, mas onde isso no acontece, eles devem incluir, no

Uma descrio das premissas e restries identificadas, assim como o tempo

esperado de concluso do projeto e as limitaes dos recursos organizacionais que podem o afetar diretamente. Para definir o Project charter, o patrocinador e gerente do projeto devem: Definir a razo de existir do projeto e seus objetivos; Determinar a prioridade do projeto relativa s iniciativas organizacionais; Definir o nvel de autoridade dado ao gerente e seus limites; Documentar as premissas e restries que tem potencial para impactar no

resultado do projeto.

Comunicando a iniciao do projeto

A ltima tarefa do processo de iniciao do projeto comunicar com eficcia o Project charter e a escolha do gerente do projeto para todas as organizaes que sofrero impacto com o mesmo. Isso facilita a cooperao inter-organizacional e execuo do projeto. A forma como essa comunicao ser feita pode variar, mas no mnimo deve envolver um relatrio e um email por parte do patrocinador do projeto para todos que contribuiro ou sofrero impacto. Alm disso, o gerente e patrocinador do projeto devem se reunir com os gerentes e contribuidores chave para que recebam o suporte e contribuio pessoais dos citados. Para comunicar a autorizao do projeto necessrio:

Identificar todos os stakeholders e organizaes que podem ser afetados

pelo projeto; Comunicar formalmente a autorizao do projeto por escrito ou

virtualmente; Reunir-se com os stakeholders mais importantes para discutir as

expectativas e preocupaes relativas ao projeto.

Planejando o Escopo

Ao planejar o escopo do projeto, voc est definindo os parmetros, como se tivesse criando uma caixa que conter o planejamento do projeto. O planejamento : como, detalhadamente, o projeto ser realizado. O escopo do projeto diz o que est dentro e fora da caixa e define os limites do projeto. Um bom planejamento de escopo uma defesa contra a deformao de escopo, por isso deve explicitar a diferena entre os componentes e entregveis necessrios dos que no so

essenciais. S aps a definio do escopo o planejamento do projeto pode comear para definir qual a melhor soluo. Para planejar o escopo do projeto necessrio: Entender e revisar os insumos do processo; Elaborar a declarao do escopo; Validar a declarao do escopo; Criar um plano de gerenciamento de escopo.

Revisar e entender os insumos do processo

As vezes a descrio do projeto e o seu Project charter so elaborados antes da escolha do gerente do projeto ou a formao da equipe do mesmo. implicam antes de proceder. patrocinador do projeto. imprescindvel que a equipe revise e entenda os documentos e no que eles Qualquer ambigidade ou inconsistncias entre a descrio do produto e o Project charter devem ser sanadas entre a equipe e o Para se fazer a reviso e chegar ao entendimento dos insumos do processo - necessrio: Revisar a descrio do produto, o Project charter, premissas e restries e

chegar a um consenso entre a equipe do projeto; Identificar conflitos, inconsistncias, e ambigidades entre esses trs

documentos citados; Tentar chegar a um consenso dentro da equipe para depois lev-lo ao

patrocinados do projeto;

partes.

Informar o patrocinador dos problemas com os documentos de insumos e

sanar as dvidas; Fazer a reviso dos documentos, atualizando o que foi concordado entre as

Desenvolvendo a declarao do escopo

Dedicar tempo para a definio precisa do escopo o melhor investimento

que a equipe do projeto pode fazer. Uma lio aprendida por gerentes de projetos experientes : as vezes necessrio ir devagar no incio para poder acelerar depois. Isso uma verdade indiscutvel na definio do escopo. Com o andamento do projeto, pode ser necessrio que haja uma redefinio do escopo original que reflita as mudanas necessrias. contemplar: A declarao do escopo deve

Razo de existir do projeto a declarao da razo de existir do mesmo A equipe do projeto comumente utilizar essas informaes para

ou sua necessidade dentro da organizao, assim como sua importncia e prioridade. negociar recursos, tempo e qualquer outro aspecto do projeto; Produto do projeto Uma breve descrio do que ser o produto do projeto; Entregveis do projeto Os entregveis do projeto so os itens que sero dos principais

entregues para completar o projeto e receber a validao

stakeholders. As vezes ao longo do andamento do projeto os entregveis podem ser melhor definidos. Para a declarao do escopo, s necessrio uma lista com os entregveis e uma breve descrio dos mesmos. Objetivos do projeto o critrio que deve ser atendido para que o projeto

seja considerado um sucesso. Esse critrio deve incluir custo, prazo e medidas de qualidade. Os objetivos devem ser mensurveis para que a equipe do projeto e os stakeholders possam verific-los posteriormente. Caractersticas de uma boa declarao de escopo so: realismo, ausncia de ambigidade, e aceitabilidade e verificabilidade mtua. Os detalhes da declarao do escopo devem ser devidamente documentados e organizados para facilitar o processo de gerenciamento do projeto. O detalhamento necessrio vai variar dependendo da complexidade do projeto. Para se desenvolver a declarao de escopo, necessrio: Escrever e concordar sobre a razo de existir do projeto; Identificar todos os entregveis requeridos para a realizao do projeto; Identificar e validar os objetivos do projeto, incluindo todas as

caractersticas citadas acima; Re-ver e atualizar a lista de premissas e restries do projeto.

Validando a declarao do escopo

Aps a elaborao da declarao do escopo do projeto, o mesmo deve ser revisto e validado pelo patrocinador do projeto. Essa a hora de verificar que h um alinhamento entre a equipe do projeto e seu patrocinador para que sejam evitadas as mudanas no escopo aps o incio do projeto. validao, necessrio: Para realizar essa

Preparar uma breve apresentao e arranjar tempo hbil para encontrar-se

com o patrocinador do projeto; Apresentar a declarao do escopo do projeto para o patrocinador, assim

como os outros stakeholders do projeto para receber crticas e feedbacks;

Realizar qualquer mudana que tenha sido identificada ser necessria

durante a apresentao e valid-la com o patrocinador do projeto.

Criando um plano de gerenciamento de escopo

Estudos recentes mostram que o fator que tem mais impacto sobre o cronograma do projeto a volatilidade de exigncias, ou a quantidade, impacto e tempo em que as mudanas no escopo so feitas e como essas decises sero tomadas e informadas aos stakeholders do projeto. gerenciamento de escopo necessrio: Definir os diferentes tipos de mudanas que provavelmente sero requeridas Para criar um plano de

durante o andamento do projeto;

Definir as categorias para avaliar o impacto.

Lio 10: Definio, Verificao e Controle de Alteraes do Escopo

Objetivos da lio:

Estudos mostram que a principal causa de falhas em projeto a inabilidade de gerenciar o seu escopo. Um bom gerenciamento de escopo implica em defini-lo bem, segui-lo da maneira mais fiel possvel, verificar com o cliente que o produto ou servio est dentro do escopo definido, e controlar qualquer eventual redefinio do escopo do projeto. gerenciveis. O PMI define a definio do escopo como: subdividir os principais entregveis do projeto em componentes menores e mais facilmente A verificao do escopo um processo de validao formal do mesmo por parte dos stakeholders do projeto. Por fim, o controle de alteraes do escopo focado nos fatores que mais podem influenciar nas alteraes do escopo e na garantia de que essas mudanas sero benficas para o projeto. Para faz-lo, necessrio registrar quando o escopo mudou e gerenciar as mudanas quando elas ocorrem. Ao final dessa lio voc deve poder: Elaborar uma EAP; Determinar como os entregveis devem ser distribudos na WBS, assim

como os decompor e validar;

Conduzir uma reviso do escopo por parte da equipe, de forma a obter a

aceitao formal do escopo definido para o projeto; Gerenciar o controle de alteraes para garantir o cumprimento do escopo,

entender as causas fundamentais das alteraes de escopo, avaliar os impactos que podem resultar da alterao do escopo e atualizar os documentos relativos ao escopo do projeto.

Termos Importantes

Definio do escopo Estrutura Analtica do Projeto EAP Decomposio Entregveis Verificao de escopo Gerenciamento de configurao Desvio de cronograma

Processo de Definio do Escopo:

Um dos trs problemas mais apresentados nos projetos que eles obtm um desempenho abaixo do esperado. Os projetos devem entregar novos projetos ou capacidades organizacionais, ser entregues conforme os requisitos definidos e atender s suas expectativas. A declarao do escopo do projeto deve ser revisada para verificar que nenhum entregvel foi ignorado. Todos os entregveis considerados muito importantes devem ser adicionados EAP nesse momento. A EAP um agrupamento dos entregveis que organiza e define o escopo total do projeto. A EAP um diagrama de rvore detalhado at o nvel de tarefas que organiza, define e mostra uma visualizao grfica do projeto. ferramenta de comunicao dos detalhes do projeto. Normalmente os nveis da EAP so divididos em: 1. 1. 1. 1. Programa Projeto Tarefa Sub-Tarefa Ela usada como uma A EAP serve como a base

para o cronograma do projeto e vrios outros elementos essenciais do mesmo.

1. 1. 2. 1. 1. 1.

Pacote de Trabalho Nvel de Esforo Tarefa Sub-Tarefa Pacote de Trabalho Nvel de Esforo

A EAP organiza o escopo do projeto de maneira que todos os entregveis estejam em seus respectivos nveis hierrquicos e detalhados conforme necessrio. Cada nvel da EAP representa uma descrio mais detalhada do que ser feito. Apesar de cada projeto ser nico, as estruturas de muitos projetos podem, at certo nvel, ser parecidas. Utilizar modelos de EAPs de projetos similares pode Para criar uma EAP, o gerente e a acelerar o processo de definio do escopo.

equipe do projeto devem realizar as seguintes tarefas: Reunir-se com as principais pessoas das reas envolvidas no projeto; Revisar a declarao do escopo focando nos entregveis chave do projeto; Fazer um brainstorm das principais fases e reas do projeto; Subdividir cada fase em grupos menores, levando em considerao quanto

deve ser realizado em cada etapa; Quando todas as fases forem definidas, os elementos, tarefas e pacotes de

trabalho devem ser definidos; Identificar qualquer entregvel adicional que ser necessrio para o

cumprimento do escopo; Organizar os entregveis mais importantes (nvel 1) em uma rvore ou

estrutura similar; Organizar os entregveis menos importantes (nvel 2 ou abaixo) abaixo dos

seus respectivos nveis 1. A decomposio uma tcnica para definir melhor o escopo de trabalho envolvido no projeto ao subdividir os entregveis em componentes menores. Esses componentes devem ser tambm decompostos at que eles se tornem facilmente estimveis, monitorveis e controlveis. Cada nvel de decomposio deve mostrar sua relao com os seus nveis superior e inferior e apresentar como o trabalho ser realizado. Aps a definio de todos os entregveis, um ndice dado a eles para identificar seus respectivos nveis na EAP. Uma definio bem feita de uma EAP requer que todos os itens sejam orados, tenham seu tempo estimado e a sua responsabilidade atribuda para algum que aceite-a e possa realizar o trabalho. A decomposio deve reduzir cada item da EAP para um nvel onde a equipe do projeto pode definir com preciso o preo e tempo de durao. Os itens que so muito grandes ou complexos devem ser subdivididos em itens mais facilmente

gerenciveis.

s vezes uma decomposio mais detalhada s pode ser realizada

durante o andamento do projeto, quando a equipe tem acesso a mais informaes sobre o mesmo. Para decompor os entregveis de um projeto, a equipe e o gerente devem: Analisar cada entregvel de nvel 1 para determinar os elementos

imediatamente abaixo deles; Analisar cada entregvel nvel 2, definido anteriormente, e determinar os

elementos nveis 3 imediatamente abaixo deles; Continuar esse processo de decomposio at o nvel em que a equipe e o

gerente possam determinar estimativas de tempo e custo, assim como realizar o seu monitoramento e controle. Never, never reveal you WBS to your customer past the third level of subordinate tasks. Else they will micro-manage you into ruin. Nunca revele para o seu cliente o terceiro nvel de tarefas da sua EAP em diante. Do contrrio, ele tentar gerenciar o seu projeto. Como fcil deixar entregveis de fora da EAP, incluir entregveis que no fazem parte do escopo, ou defini-los de forma confusa e ambgua, importante que a EAP seja validada. Para faz-lo, a equipe do projeto deve responder as seguintes perguntas: A lista de entregveis descreve detalhadamente e satisfaz a declarao do

escopo? Todos os entregveis esto dentro da declarao do escopo? O cliente ficar satisfeito em receber apenas esses entregveis? Podemos atribuir responsabilidade por cada um dos entregveis a uma

pessoa ou organizao? Os entregveis foram descritos claramente?

Se a resposta para qualquer uma dessas perguntas for no, quaisquer adies, alteraes ou excluses necessrias devem ser realizadas. A EAP final deve ser revisada com especialistas tcnicos no conhecimento envolvido no projeto e gerentes de projeto experientes. Essa reviso pode trazer muitos benefcios, j que a experincia dessas pessoas em projetos similares os ensinou coisas que podem agregar valor equipe. Alm destes, o patrocinador e cliente(s) do projeto devem aprovar a EAP. Normalmente os patrocinadores dos projetos no esto totalmente cientes do trabalho necessrio para cumprir o Project Charter, por isso a visualizao da EAP importante para ele ter um entendimento do esforo que ser realizado. Alm disso, os clientes tm muita dificuldade em conseguir especificar com detalhes os produtos ou servios com os quais eles no tm muita familiaridade. A EAP pode ajud-los a compreenderem suas necessidades e comunicarem-se melhor com a equipe do projeto. imprescindvel que a equipe do

projeto receba o mximo de feedbacks possveis no incio do planejamento do projeto para que haja um alinhamento nas expectativas dos stakeholders. validar a EAP, o gerente do projeto e sua equipe devem: Revisar a EAP em uma reunio entre a equipe e especialistas no Para

conhecimento envolvido no projeto; Identificar quaisquer entregveis que tenham sido esquecidos, esto fora do

escopo ou foram descritos de maneira confusa ou ambgua; Realizar as correes necessrias; Revisar a EAP com os stakeholders mais importantes do projeto e receber

seus feedbacks e aprovao; Revisar a EAP com o patrocinador do projeto e receber aprovao formal.

Processo de Verificao de Escopo

A equipe do projeto deve avaliar minuciosamente os resultados do projeto antes de pedir a aprovao do cliente e stakeholders. Essa avaliao permite que a equipe identifique qualquer requisito que no tenha sido preenchido e antecipe o que ser necessrio realizar para obter a validao da fase ou projeto. importante que a declarao do escopo seja atualizada, j que ela certamente mudou durante o ciclo de vida do projeto. A declarao do escopo atualizada deve cumprir os requisitos que sero utilizados para a validao final do cliente. Potenciais desentendimentos entre a equipe do projeto e os stakeholders sobre esses requisitos podem ser minimizados se a alterao do escopo tiver sido realizada baseando-se no plano de gerenciamento de escopo. Os status do projeto, assim como qualquer requisito que no tenha sido preenchido e que pode condenar ou atrasar a validao, devem ser revistos com o patrocinador do projeto. Para realizar a reviso dos resultados do projeto a equipe e seu lder devem: aes; Conduzir reunies para comparar a execuo do projeto com o escopo

planejado; Atualizar os critrios de cancelamento do projeto; Chegar a um consenso sobre quanto o escopo j executado preenche os

critrios de validao do projeto; Identificar requisitos no preenchidos que necessitam de uma tomada de

Revisar e validar os resultados do projeto com os stakeholders.

Os clientes e stakeholders tambm devem realizar as suas avaliaes da fase ou projeto antes de validarem. Essas avaliaes podem variar de simples a elaborados testes.

A quantidade de recursos e envolvimento necessrio da parte da equipe para dar auxilio avaliao do produto varia conforme sua complexidade. Muitas vezes os clientes validam o escopo do projeto com certas condies, deixando algumas questes pendentes. completa do cliente. A validao de responsabilidade do gerente do dentro de um determinado prazo projeto resolver essas questes em tempo hbil e obter a validao formal e particularmente importante para projetos que tem seus custos relacionados durao e que requerem a validao formal antes do pagamento referente mesma. Para obter a validao do escopo do projeto, o gerente e sua equipe devem:

Organizar e conduzir uma avaliao formal do escopo do projeto com os

stakeholders; Quando necessrio, chegar a um acordo com os stakeholders sobre o escopo

do projeto; Elaborar e implementar um plano para resolver questes levantadas no item

anterior;

Requerer validao formal dos stakeholders.

Processo de controle de alterao do escopo Qualquer alterao no escopo de um projeto pode implicar em mudanas em outras reas do planejamento do projeto, incluindo cronograma, custo, qualidade, risco e satisfao do cliente. Por isso to importante gerenciar os pedidos de Para alterao do escopo de uma forma disciplinada como descrito no planejamento de gerenciamento de escopo e no sistema geral de controle de alteraes. satisfaz-los, o gerente do projeto deve: Revisar os critrios de alterao do escopo e procedimentos com a equipe do

projeto, como definido no sistema geral de controle de alteraes e planejamento de gerenciamento de escopo; Requerer que qualquer pedido de alterao de escopo seja formalmente

gerenciado; Monitorar o andamento do projeto com a equipe para garantir que nada seja

produzido fora do escopo ou que ele seja alterado sem permisso.

O Gerenciamento de configurao possibilita os nveis apropriados de reviso e aprovao para mudanas no projeto. Isso estrutura um nico ponto onde podem ser requeridas as alteraes. Para que qualquer alterao no escopo seja realizada, imprescindvel saber: Qual o custo da mudana e se o mesmo justificvel;

Qual o impacto na qualidade e no custo das verificaes de qualidade; Se a mudana realmente necessria; Qual o impacto no cronograma.

Observao: Configuration management (CM) is a field of management that focuses on establishing and maintaining consistency of a system's or product's performance and its functional and physical attributes with its requirements, design, and operational information throughout its life.[1] For information assurance, CM can be defined as the management of security features and assurances through control of changes made to hardware, software, firmware, documentation, test, test fixtures, and test documentation throughout the life cycle of an information system.

importante saber as causas mais freqentes de pedidos de alterao de escopo. So elas: Erros ou omisses Devido ao fato de que muitas vezes difcil para o Ao decorrer do mesmo, eles acabam aprendendo mais sobre seus Isso normalmente acarreta num acrscimo no custo e atraso no

Cliente descrever com preciso as suas necessidades durante o planejamento do projeto. acordados. problemas e a tendncia que peam produtos diferentes dos que haviam sido cronograma do projeto. Oportunidades de aumento no valor do projeto Oportunidades inesperadas Nesses casos uma boa anlise deve ser feita para

frequentemente surgem durante o projeto, mas para aproveit-las, necessrio alterar o escopo do mesmo. pesar as vantagens e desvantagens de alterar o escopo, levando em considerao quanto ele pe em risco a qualidade do projeto. Presso da concorrncia A concorrncia no para de trabalhar enquanto os Eles podem lanar novos produtos, acessrios, e

projetos so realizados.

funcionalidades enquanto o projeto est em andamento. Isso pode forar a equipe do projeto a ter que reavaliar o planejamento do projeto e realizar as alteraes necessrias para que o produto continue sendo competitivo; Atraso no cronograma O atraso no cronograma fora a equipe do projeto a

reavaliar o escopo, para que o projeto no dure mais tempo do que o planejado. Quando o cronograma original no pode ser cumprido, os impactos de atrasar o projeto podem ser maiores do que os de reduzir o escopo, por isso essa anlise deve ser feita, principalmente na perspectiva da satisfao do cliente. Para analisar os pedidos de alterao de escopo, o Gerente do projeto deve: Identificar a raiz da causa da alterao; Estimar os benefcios e custos de realizar a alterao;

Identificar as implicaes da alterao de escopo e os outros elementos do

planejamento do projeto, incluindo tempo, custo e qualidade; Avaliar os riscos envolvidos em realizar a alterao; Avaliar os impactos no cliente; Discutir as implicaes da mudana com os stakeholders chave, incluindo o

patrocinador do projeto e o cliente. S aps uma avaliao minuciosa dos potenciais impactos da alterao do escopo, pode ser autorizada a mudana, e seus resultados monitorados. Os recursos devem ser preparados para a alterao em tempo hbil, e aes imediatas podem ser necessrias caso a alterao no ocorra como planejado. Para autorizar e monitorar a alterao de escopo, o Gerente do Projeto deve: Garantir que as aes propostas sejam autorizadas e definidas no plano de

gerenciamento de escopo e no sistema de controle de alteraes; Assegurar que as pessoas certas esto preparadas para realizar as

mudanas necessrias em tempo hbil;

Requerer feedbacks e avaliaes formais das alteraes; Avaliar qual teria sido o resultado se a execuo seguisse o que havia sido

planejado antes; Realizar novas alteraes quando necessrio.

Todas as alteraes de escopo que afetem o escopo do projeto devem ser formalmente do projeto. registradas nos documentos do projeto. Esses incluem: requerimentos, especificaes, desenhos, declarao de escopo e estrutura analtica Ao no atualizar esses documentos, pode haver confuso no Alm disso, aps o andamento do projeto, j que as informaes sero dbias.

projeto, o mesmo deve servir de aprendizado para outras pessoas e caso os documentos no sejam atualizados, suas validades como documentos de lies aprendidas condenada. Para realizar as atualizaes, a equipe do projeto deve: Atualizar documentos afetados pela alterao; Utilizar um sistema de controle numrico consistente para identificar as

atualizaes e suas respectivas datas;

Revisar os documentos atualizados para conferir sua preciso e distribuir as

partes necessrias para cada stakeholder; Documentar as causas de alteraes de escopo, as decises e outras lies

aprendidas vindas das alteraes de escopo.

Lio 11: Definio, Sequenciamento e Estimativa da Durao das Atividades

Objetivos da Lio: Uma atividade, em Gerenciamento de Projetos, foi definida com a menor unidade de trabalhado usada para definir a lgica de um projeto. De maneira geral, atividades possuem as seguintes caractersticas: uma durao definida, um relacionamento lgico com as outras atividades no projeto, usam recursos como pessoas, matrias e lugares e possuem um custo associado. Sendo assim, todas atividades em um projeto precisam ser classificadas ou definidas, priorizadas ou seqenciadas, e tempo ou durao aplicados elas para serem propriamente gerenciadas. At o final dessa lio voc deve estar apto a: Identificar atividades ou tarefas especificas que devem ser realizadas para

alcana os objetivos do projeto Identificar e documentar dependncias interativas Estimar o numero de perodos de trabalho necessrios para completar

atividades e tarefas individuais

Termos Chave Definio Lista de atividades Dicionrio de atividades ou tarefas Seqenciamento de atividades Relacionamentos de precedncia Diagrama de rede Dependncias Dependncias a critrio pessoal (do Gerente) Dependncias por Obrigao Dependncias Externas Grfico de Gantt Estimando Durao

Estimativas Determinsticas Estimativas Probabilsticas

Definio da Atividade Defina a Lista de Atividades Em um processo anterior, Definio de Escopo, a preocupao era identificar as sadas ou entregveis tangveis do projeto. O Processo de Definio das Atividades d uma passo alm, pois ele identifica as atividades de alto nvel que sero necessrias para produzir cada entregvel. Os responsveis pelos entregveis devem entender o trabalho envolvido e devem trabalhar com as pessoas que iro realizar o trabalho em si para definir as atividades necessrias. Pode servir de ajuda procurar a lista de atividades de projetos parecidos ou buscar a experincia de pessoas que tiveram projetos parecidos. Todas as atividades de alto nvel devem ser registradas em uma lista de atividades de maneira hierarquizada na EAP. Embora todo projeto seja nico, a maioria dos projetos vai se parecer com outro em algum nvel. Uma lista de atividades, ou uma parte da lista, de um projeto anterior pode ser usada de modelo para um novo projeto. importante incluir um cdigo de identificao dos entregveis para os quais as atividades esto relacionadas quando se est criando a lista de atividades. Para definir a lista de atividades necessrio realizar as seguintes tarefas: Decompor as atividades de um projeto Criar um dicionrio de atividades ou tarefas Atualizar a Estrutura Analtica do Projeto

Decompondo Atividades Parecido com a estrutura analtica dos entregveis no processo de Definio do Escopo, todas as atividades de alto nvel devem ser subdivididas em menor, e mais gerenciveis, sub-atividades. Para cada atividade de alto nvel, o responsvel deve pensar se a atividade poderia ser quebrada em componentes lgicos que definiriam melhor o trabalho a ser executado. Geralmente, uma definio correta das atividades quer dizer que elas podem ser individualmente agendadas, oradas e designadas para uma pessoa especifica que vai aceitar a responsabilidade pela sua concluso. Atividades so, ento, incorporada na lista de atividades j existente. A lista final deve ser verificada para garantir sua completitude e garantir que a lista ultrapasse os limites definidos na declarao do escopo. Isso atingindo quando se garante que todas as atividades de baixo nvel e as sub-atividades so ambas essenciais e suficiente para se concluir o trabalho. Correes e modificaes podem ser necessrias durante a vida do projeto. Atividades devem ser rapidamente explicadas para deixa claro o trabalho que deve ser feito e evitar desentendimentos assim que o projeto comear. Todas as explicaes das atividades devem ser

compiladas com as definies dos entregveis dentro do dicionrio da estrutura analtica do projeto. Para decompor as atividades do projeto, o Gerente de Projetos deve realizar as seguintes tarefas: Analisar cada atividade de Nvel 1 para determinar as prximas atividades

de Nvel inferior, Nvel 2 Analisar cada atividade de Nvel 2 para determinar as prximas atividades

de Nvel inferior, Nvel 3 Continuar decompondo as atividades em atividades de nveis inferiores

(Nvel 4, etc.) at cada atividade estar suficientemente detalhada para se conseguir estimar, monitorar e controlar EAP Criar uma breve explicao de cada atividade para garantir que no havero

mal entendidos pelos membros da equipe Compilar a lista de atividade e as respectivas explicaes no dicionrio da

Criando o Dicionrio de Atividades ou Tarefas Atividades dentro do projeto so normalmente interdependentes umas com as outras para serem concludas. Por essa razo, importante garantir que no existem suposies erradas ou mal entendidos pelos membros da equipe sobre o que dever ser feito e o que indica que o trabalho foi concludo. Os responsveis pelos entregveis e atividades devem descrever brevemente cada atividade na lista e deixar claro o critrio de concluso das atividades.

Atualizando a EAP A equipe do projeto pode se deparar com entregveis que no foram contemplados durante a Definio de Escopo ou pode decidir que as descries iniciais dos entregveis precisam ser melhor explicadas ou corrigidas. Quando isso ocorre a equipe precisa atualizar a EAP e todos os documentos afetados para refletir essas mudanas. Situaes desse tipo podem ser esperadas quando o projeto envolve o desenvolvimento de novos produtos. Para atualizar a EAP, o Gerente de Projeto e sua equipe devem realizar as seguintes tarefas: inicial Designar responsveis para cada novo entregveis e ter o aceite do membro Identificar qualquer entregveis necessrio que no esteja includo na EAP

designado Incluir qualquer novo entregvel identificado na EAP e na matriz de

responsabilidades

Sequenciamento das Atividades O primeiro passo no seqenciamento das atividades determinar a seqncia dos eventos identificando as tarefas sobre as quais o trabalho dependente. Os membros da equipe devem analisar suas prprias listas de tarefas e identificar o que necessrio para comear cada nova atividade. Fazendo isso, cada membro da equipe do projeto deve considerar cuidadosamente cada dependncia a critrio, obrigatria ou external que o trabalho que est sendo executado possui. Existem quatro tipo de dependncias: fim-fim, onde a atividade anterior tem que ser concluda antes da prxima atividade poder terminar; incio-incio, onde a atividade anterior tem que ser iniciada para que a prxima atividade possa iniciar; incio-fim, onde a atividade anterior tem que ter sido iniciada para que a prxima atividade possa terminar. Nessa ponto, as dependncias de cada atividade devem ser registradas no marcador das tarefas. Para identificar relaes de predecesso, o Gerente de Projeto junto com sua equipe deve realizar as seguintes tarefas: Identificar Relacionamentos de Predecesso Construir um Diagrama de Rede Revisar e Validar o Diagrama de Rede Atualizar o Diagrama de Rede e a Lista de Atividades

Identificando Relaes de Predecesso Quase todas as atividades so dependentes de pelo menos uma atividade e essas dependncias devem ser identificadas. Dependncias podem ser obrigatrias, a critrio ou externas em relao ao produto que est sendo desenvolvido. Dependncias obrigatrias so aquelas inerentes a natureza do trabalho que est sendo executado e ser, na maioria das vezes, resultado de limitaes fsicas (exemplo: um programa que no pode ser testado antes de ser programado). Dependncias a critrio so aquelas que so definidas pela equipe de gerenciamento do projeto. Essas so normalmente baseadas em procedimentos que se provaram confiveis, disponibilidade de equipe ou uma seqncia especifica que foi definida mesmo existindo outras opes (exemplo: dois mdulos de um software podem ser programados ao mesmo tempo, mas vo ser feitos em seqncia, pois s tem um programador qualificado para realizar o servio). Dependncias externais so aquelas que aparecem devido ao relacionamento das atividades do projeto com as atividades de fora do projeto (exemplo: um modulo no pode ser terminado at a entrega da ferramenta necessria para compilar o cdigo). As relaes de predecesso junto com as atividades definem quais atividades devem vir antes das outras. No exemplo acima, um programa deve ser programado antes de ser testado. A atividade de programao seria chamada de predecessora e a atividade teste seria chamada de sucessora. Sempre se pergunte, quais atividade devem ser concludas antes dessa atividade poder comear? Esse tipo de relacionamento onde uma atividade deve terminar antes da

outra poder comear chamada de fim-incio. Esse o tipo de dependncia mais comum. Essas relaes de predecesso devem ser identificadas para se criar o cronograma do projeto. Existem outros tipos de dependncias que tambm podem ser usados: Fim-fim, onde a atividade anterior deve ser finalizada antes da prxima

atividade poder terminar Incio-incio, onde a atividade anterior deve comear antes da prxima

atividade comear Incio-fim, onde a atividade anterior deve comear antes da prxima

atividade poder terminar Para identificar as relaes de precesso nas atividade do projeto deve-se: Revisar cada atividade e determinar quais outras atividade, caso existam,

elas dependem para comear Completar o passo acima com todas as dependncias obrigatrias, a critrio

e externas de todas as atividades

Construindo um Diagrama de Rede Um diagrama de rede uma ferramenta essencial para o planejamento de projetos complexos. Ele fornece uma representao visual de como as atividades do projeto avanam. Para projetos muito simples, um grfico de barra ou de Gantt so adequados para simplesmente mostrarem onde todas as atividades comeam e terminam. No entanto, quando os projetos se tornam mais complexos, alguma forma de diagrama de rede necessrio. Para construir um diagrama de rede necessrio: branco Colar o papel de comeo do projeto no canto esquerdo do papel e o papel Escrever todas as atividade em post it, incluindo uma para o comeo do

projeto e uma para o final do projeto Colar juntas vrias cartolinas e pendur-las na parede ou usar um quadro

final do projeto do canto direito extremo Colocar uma referencia a lista de dependncias e as atividades que no tem

predecessoras imediatamente a direita do papel de incio Desenhar setas do papel de comeo para todas as atividades que no tem

predecessoras (cada uma dessas vai virar o comeo do caminho da rede) Colocar, para cada caminho, as atividades sucessoras seguintes da esquerda

para direita de acordo com os relacionamentos

Continuar mapeando a sequencia de cada caminho e desenhar setas

conectando-os (atividades podem ter mltiplas dependncias com seus caminho e entre os caminhos) Trocar e rearrumar as dependncias quando necessrio at o time chegar ao

consenso Conectar as ltimas atividades com o papel de final com setas

Vrios softwares de gerenciamento de projetos podem fazer isso, mas eles precisam de equipamentos adicionais como grandes impressoras.

Revisando e Validando o Diagrama de Rede As dependncias entre as atividades no diagrama de rede tem um grande variedade de implicaes importantes que precisam ser revisadas e validadas. Em primeiro lugar, todas as dependncias devem ser negociadas e aceitas pelos responsveis de cada atividade. Se a sada de uma atividade de uma pessoas necessria para outra iniciar o trabalho, ento essa pessoa deve entender a importncia de concluir a atividade em tempo e na forma necessria pelo prximo. Em segundo lugar, devem existir vrias maneiras de realizar o mesmo trabalho e existem algumas alternativas que so mais rpidas. Executar certas atividades de maneira seqencial, ao invs de executar em paralelo, vai demorar mais tempo para a concluso. Suposies feitas sobre dependncias a critrio podem ter um grande impacto no cronograma do projeto. Em terceiro lugar, as partes interessadas chave devem entender a lgico por trs do diagrama de rede para no ocorrerem mal entendidos ou surpresas. Para revisar e validar o diagrama de rede necessrio: Revisar todas as dependncias com os responsveis pelas atividades e obter

sua aceitao Revisar o diagrama de rede com outras pessoas que entendem do assunto

para obter opinies diferentes sobre como o trabalho vai ser melhor alcanado Examinar todas as dependncias a critrio e procurar oportunidades para

realizar mais atividades em paralelo se estiver difcil de atender o cronograma Revisar o diagrama de rede com as partes interessadas chave para obter

feedback e compreenso

Atualizando o Diagrama de Rede e a Lista de Atividades Bem parecido com as atualizaes que o processo de definio de atividades pode gerar no WBS, o seqenciamento de atividades vai resultar em atualizaes na lista de atividades. Mudanas tipicamente vo incluir a adicionar de atividades esquecidas, juntar atividades relacionadas ou redundantes ou dividir atividades para executar em paralelo. importante atualizar a documentao sempre que

mudanas so feitas para garantir que existir um histrico claro e que todos esto trabalhando com o mximo de informao recente. Para atualizar o diagrama de rede e a lista de atividades deve-se: Fazer todas as mudanas necessrias no diagrama de rede e na lista de

atividades Distribuir as mudanas para os membros da equipe e as outras partes

interessadas afetadas

Estimando a Durao Na maioria das organizaes o Gerente de Projetos desenvolve as estimativas de durao do projeto como um todo tendo o auxilio dos membros da equipe. Algumas organizaes chegam a ter os membros da equipe estimando a durao de suas prprias atividades. Para alcanar isso, primeiro deve-se calcular a quantidade de tempo que iria normalmente precisar para completar a atividade, levando-se em considerao em considerao que os recursos alocados estariam funcionando na sua capacidade total. Restries, como processamento de dados ou reunies, so adicionadas as projees para determinar o tempo real que vai ser necessrio para realizar as atividades. Os grupos trabalham juntos para garantir que todas as estimativas so realistas e alcanveis dado os recursos que estaro disponveis para cada atividade. Estimativas que no so razoveis so ajustadas de acordo. Para criar uma estimativa inicial de durao e esforo necessrio realizar as seguintes tarefas: Estimar as Capacidades de Recurso Comprar o projeto atual com experincias passadas Estimar Durao das Atividades Atualizar a Lista de Atividades

Estimando as Capacidades dos Recursos No Gerenciamento de Projetos existem dois tipos de tempo: esforo e durao. Esforo a quantidade de tempo que precisaria para concluir uma atividade se a pessoa ficasse o tempo todo trabalhando nisso sem interrupo. Durao a quantidade de tempo que uma atividade vai precisar quando outras responsabilidades esto envolvidas. Por exemplo, um desenvolver pode estimar que precisaria de 80 horas-homem ou duas semanas para escrever um cdigo. No entanto, os desenvolvedores de software tambm iro realizar outras atividades como atendimento de suporte ao cliente, reunies, escrever especificaes tcnicas e outras atividades necessrias. Isso significa que o desenvolvedor ir na verdade usar menos de 8 horas por dia para trabalhar no cdigo. Se o desenvolvedor consegue gastar 4 horas por dia no desenvolvimento, ento a durao total da

atividade seria 20 dias e no 10. Oitenta horas usado nesse exemplo porque normalmente, na industria, 80 horas a quantidade mxima de horas alocada para o menor esforo na EAP. Isso chamado de pacote de trabalho. Normalmente as pessoas criam estimativas de esforo razoveis, mas a tendncia natural de ser muito otimista sobre o que pode ser alcanado. Problemas aparecem com a estimativa de esforo quando se tenta estimar atividades que so novas ou contem risco tcnicos desconhecidos. O principalmente problema de estimativa, no entanto, acontece quando se assume que se ter mais tempo por dia ou semana do que a realidade. Isso acontece quando se subestima a quantidade de tempo noprodutivo em um perodo e, conseqentemente, a durao da atividade. Estimar duraes precisamente comea com um entendimento realstico de quanto tempo dedicado ser realmente gasto. Os responsveis pelas atividades, quando Possvel, devem criar estimativas das suas prprias atividades, ao invs do Gerente de Projetos. Isso responde a duas metas importantes: Garante que os responsveis pelas atividades se sintam responsveis pelas

suas estimativas Garante que as pessoas mais prximas e preparadas para o trabalho faam

a estimativa Sempre que outras pessoas, que no as que esto realizando as tarefas, fazem as estimativas, as tarefas devem ser validadas com aqueles que iro de fato fazer o trabalho antes de qualquer comprometimento formal. Para criar estimativas iniciais de durao e esforo necessrio: Estimar o esforo necessrio para cada atividade Determinar quanto tempo cada responsvel pela atividade vai pode

realmente gastar nela em determinado perodo Determinar durao das atividades ajustando a estimativa de esforo pela

quantidade de tempo dedicado Colocar os membros da equipe para revisarem realisticamente as

estimativas uns dos outros e darem-se feedbacks Ajustar as estimativas iniciais quando necessrio Registrar as premissas de cada estimativa

Comparando o Atual Projeto com Experincias Passadas Informaes histricas e experincias anteriores com projetos similares podem melhorar a preciso das estimativas preliminares. Essas informaes podem ser obtidas examinando os registros de projetos anteriores e conversando com pessoas que entendam do assunto, como Gerentes de Projetos e membros experientes. Planos e cronograma de projetos anteriores normalmente esto disponveis para reviso.

O problema ocorre quando as organizaes e os projetos no mantm registros precisos entre o desempenho atual do projeto em relao ao que foi planejado. Isso normalmente torna difcil sabe quanto cada atividade durou realmente para ser concluda e em quais condies elas foram feitas. Embora imperfeitas, as estimativas de projetos anteriores podem fornecerem boas comparaes. Todos os projetos so diferentes e as circunstancias envolvidas em cada projeto iro afetar a durao das atividades. Aquele envolvidos nas estimativas devem comparar as informaes historio e as experincias passadas com as condies do atual projeto para buscar semelhanas e diferenas. Os fatores que devem ser considerados so: dificuldades tcnicas, ambiente do projeto, disponibilidade e capacidade dos recursos e as restries do projeto. Para se atualizar as informaes histricas dos projetos deve-se: plano Revisar as informaes para achar entregveis e atividades similares Comparar as atuais estimativas de durao com as estimativas de outros Obter documentao de projetos anteriores parecidos, incluindo: declarao

do escopo do projeto, EAP, diagrama de rede, lista de recursos, cronograma e o

projetos Ajustar as estimativas de durao quando indicado

Estimando a durao das atividades Algumas atividades so mais fceis de estimar precisamente do que outras. As mais fceis so as estimativas determinsticas, que so estimativas de tempo para as atividades as quais a durao esperada baseada em restries fsicas. Por exemplo, um fundao de concreto vai demorar um tempo para secar independentemente no numero de pessoas trabalhando nela. As mais comuns e difceis estimativas so as probabilsticas, que so estimativas para atividades que so incertas devido a falta de experincia, riscos tcnicos ou circunstancias imprevisveis para as quais a equipe do projeto tem pouca ou nenhuma experincia. Nos casos onde existem uma grande gama de estimativas para as atividades, devido a incertezas envolvidas, o otimista e o pessimista devem ser balanceados pela estimativa mais provvel usando a formula convencional como a figura 64 no PMBOK. Para fazer ajustes de probabilidade necessrio: Identificar as estimativas otimistas aquela que acha que tudo ir de

acordo com os planos Identificar as estimativas mais provveis aquela que a maioria das pessoas

acreditam que realista

 errado

Identificar as estimativas pessimistas aquele que acha que tudo ir dar

Balancear as trs estimativas usando a formula de balanceamento

Atualizando a Lista de Atividades O processo de planejamento tem vrios check points e balanceamentos ao longo do caminho para garantir que o cronograma final seja o mais completo e preciso possvel. Estimar a durao das atividades outro ponto no qual mudanas necessrias nas atividades do projeto devem ser descobertas e a lista de atividades original deve ser atualizada para refletir essas mudanas. Para atualizar a lista de atividades necessrio: Identificar adies, modificaes ou excluses na lista de atividades original Atualizar a lista de atividades e distribu-la para os membros da equipe

Lio 12: Controle e Desenvolvimento de Cronograma

Objetivos da Lio: Controle e desenvolvimento de cronograma para um projeto necessita que se determine datas de inicio e fim para todas as atividades. Se essas datas no forem realistas, o projeto vai ter a sua concluso colocada em risco. O Gerente de Projetos deve se preocupar no s com estabelecer uma data realista de inicio e fim para as atividades, mas tambm com os fatores que influenciam o projeto e podem gerar mudanas no cronograma para garantir que essas mudanas so benficas. Se o Gerente determinar que o cronograma mudou, ento de sua responsabilidade gerenciar as mudanas enquanto elas ocorrem. Desenvolvimento e controle do cronograma deve ser totalmente integrado com os outros processos chave de planejamento do projeto. At o final dessa lio voc deve estar apto a: Analisar a Seqncia de Atividades, a Durao das Atividades e os Recursos

Necessrios para criar o cronograma do projeto Controlar todas as mudanas no cronograma do projeto

Termos Chave

Mtodo do Caminho Critico Flutuar Sobre Alocao Nivelamento Passar para Frente Passar para Atrs Desleixo

Desenvolvimento de Cronograma A equipe do projeto normalmente insere tarefas, duraes e dependncias para suas responsabilidade manualmente para o Gerente do Projeto ou no programa de gerenciamento de projetos. O software automaticamente calcula cada cronograma e coloca as atividades ao longo do caminho critico. Se feito manualmente, o Gerente de Projetos quem faz esse trabalho. Todos os cronogramas podem ser juntados dentro da rede de atividades do projeto para analise. Para desenvolver o cronograma necessrio realizar as seguintes tarefa: Calcular o Cronograma Preliminar do Projeto Calcular o Cronograma Nivelado de Recursos do Projeto Documentar as Premissas do Cronograma Criar o Plano de Gerenciamento do Cronograma Atualizar as Necessidades de Recursos

Controlando o Cronograma Preliminar do Projeto A abordagem mais usada para calcular o tempo necessrio para o cronograma do projeto o Mtodo do Caminho Critico (CPM Critical Path Method). O CPM basicamente identifica o caminho de maior durao dentro do cronograma. possvel tem mais de um caminho critico em um projeto quando as duraes so iguais. A adio de tempo no caminho critico no apenas determina quando o projeto dever terminar, mas tambm nas iniciais e finais que as atividades podem ter. A diferena entre as primeiras e as ltimas datas possveis para termino chamada de flutuao, j que as atividades podem ser concludas em qualquer momento entre essas datas sem afetar a data de concluso geral do projeto. Outras maneira de definir o caminho critico que ele o caminho (s) no cronograma do projeto que tem flutuao zero. Qualquer atividades que concluda apos a ltima data possvel entra automaticamente no caminho critico e uma ameaa para atrasar a concluso geral do projeto. Para calcular o Cronograma preliminar do projeto necessrio realizar as seguintes tarefas:

Inserir todas as atividades, dependncias e sua duraes em um projeto de

gerenciamento de projetos nico Se todas as atividades esto conectadas com predecessoras e sucessoras o

programa ir automaticamente calcular o caminho critico junto com as datas de inicio e fim programadas Se no houver um programa disponvel, ento siga cada caminho do

cronograma e manualmente determina as primeiras e as ltimas datas para cada atividade zero) O caminho critico vai determinar o marco de final e, ento, a primeira data Identificar essas atividades no caminho critico (aquelas com flutuao

para concluso possvel do projeto

Calculando o Cronograma Nivelado dos Recursos do Projeto O diagrama de rede e o cronograma preliminar so baseados na estimativa de durao das atividades e suas relaes lgicas das atividades, sem se preocupar com os recursos. O cronograma deve ser analisado para determinar a razoabilidade das premissas dos recursos alocados. Por exemplo, embora tecnicamente possam no existir obstculos para se realizar duas tarefas em paralelo, elas podem ter que ser concludas com o mesmo recursos. Isso pode resultar em situaes impossveis onde o mesmo equipamento est agendado para ser usados em dois lugares diferentes no mesmo tempo ou um individuo chave est programado para trabalhar tempo integral em duas atividades simultaneamente. Nesses casos, o tempo das atividades deve ser mudado caso as restries dos recursos no puderem ser superadas. Para nivelar os recursos dos projetos necessrio: Assegurar que todas as atividades tem dono Criar um perfil dos recursos demonstrando a carga de trabalho para todas as

atividades pelo tempo proposto no cronograma preliminar Identificar os momentos onde as pessoas possuem cargas de trabalho

irrealistas (mais de 8 horas por dia ou 40 horas p semana) Caso todas as alternativas falharem para nivelar as super alocaes do

projeto, deve-se determinar que recursos adicionais sero necessrios para tornar o cronograma realista Cuidado: Lembre-se, Uma mulher pode ter um bebe em 9 meses. No entanto, nove mulheres no podem ter um bebe em 1 mes. Vrios programas de computador podem automaticamente nivelar seus recursos super alocados. Eles fazem isso espalhando os recursos pelo tempo e, em muitos casos, estendendo os projetos bem alem da data de concluso planejada. Cuide do nivelamento dos recursos com prudncia.

Documentando as Premissas do Cronograma J que todos os cronogramas so feitos em cima de conhecimento disponvel, projees e premissas, importante documentar essas premissas chave para validaes e referencias de recursos futuras. chave, Premissas execuo normalmente em tempo de incluem: a disponibilidades terceirizados,

estabilidade dos requerimentos dos produtos, tecnologia, etc.. Se essas premissas se mostrarem invalidas no futuro, ento provvel que ocorram impactos negativos no projeto. Essas premissas tambm sero usadas como entradas para os seguintes processos: Identificao de Risco Quantificao de Risco Desenvolvimento da Resposta

Para documentar as premissas de cronograma necessrio realizar as seguintes 3 tarefas: Revisar as atividades do caminho critico e identificar premissas que, caso

invalidadas, podem impactar negativamente o cronograma Identificar qualquer outra premissas de cronograma chave Documentar as premissas e seus impactos negativos potenciais ao

cronograma do projeto

Criando um Plano de Gerenciamento do Cronograma A nica coisa que uma equipe de projeto pode esperar o fato de que as coisas no iro ocorrer de acordo com o planejado e as mudanas no cronograma vo acontecer. J que as inevitveis mudanas no cronograma podem ser antecipadas, as maneiras de gerencias tais mudanas devem ser acordadas antes delas ocorrerem. Isso deve incluir a definio de nveis de severidade dos impactos potencias ao cronograma e como as decises resultantes sero incorporadas e comunicadas. A definio de nveis de severidades deve ser simples, como: Baixa o impacto pode ser gerenciado dentro da equipe sem grandes

conseqncias Media o impacto vai afetar outras variveis do projeto ou atividades, mas

no ameaa o cronograma geral Severa impacto que ameaa o cronograma geral e o contratante deve ser

envolvido na soluo Esse passo diretamente relacionado com outros 2 processos do PMBOK: Controle do Cronograma

Controle Geral da Mudana

Para criar o Plano de Gerenciamento da Mudana necessrio: projeto Determinar como as mudanas no cronograma so comunicadas para as Definir nveis de severidade para os possveis impactos no cronograma Identificar quem precisa estar envolvido em cada nvel Determinar como as mudanas sero incorporadas no cronograma do

partes interessadas

Atualizando as necessidades de Recursos A estimativa inicial dos recursos necessrios para concluir a declarao de escopo do projeto ir invariavelmente mudar como resultado do conhecimento adquirido ao longo do processo detalhado de cronograma. Essas mudanas, que podem ser de qualquer tipo ou quantidade, precisam ser refletidas na necessidade de recursos como definido do Planejamento de Recursos no PMBOK. Para atualizar a necessidade de recursos deve-se: Identificar mudanas sobre as estimativas de recursos anteriores Refletir essas mudanas nas necessidades de recursos definidas no

Planejamento de Recursos

Controle do Cronograma O Gerente de Projetos controla as mudanas no cronograma atravs do uso do sistema geral de controle da mudana. Os membros da equipe do projeto devem resolver todos os problemas dentro de sua prpria rea funcional, no menor nvel possvel. Qualquer situao que tem o potencial de afetar a data final ou afetar as atividades seguintes, necessita ser levada para cima (superior hierrquico) e reportada como um impacto para o projeto. As situaes que podem impactar negativamente o projeto incluem, mas no se limitam a: Perda de Datas Marcadas Perda, Atraso ou Dano de Equipamentos Problemas de Coordenao

Para manter os problemas sobre controle, a gerencia do projeto resolver os impactos causados dentro de 48 horas. Se a gerencia do projeto incapaz de resolver o impacto dentro do tempo, o problema deve ser escalado para o maior nvel de superviso do Gerente de Projetos. Na maioria dos casos essa pessoa pode ser o contratante. Para se manter dentro do plano de gerenciamento do cronograma e o sistema

geral de controle da mudana necessrio que o Gerente de Projetos revise o progresso da equipe e os resultados dos trabalhos para garantir que no ocorram mudanas no cronograma no autorizadas. Para se manter dentro do plano de gerenciamento do cronograma e o sistema geral de controle da mudana necessrio realizar as seguintes tarefas: Checar todos os Procedimentos de Controle para Garantir que esto sendo

seguidos Analisar os Pedidos de Mudanas no Cronograma Autorizar e Gerenciar Mudanas no Cronograma do Projeto Atualizar os Documentos relacionados ao Cronograma

Checando Todos os Procedimentos de Controle para Garantir que Esto Sendo Seguidos Mudanas no cronograma do projeto pode ser grande impacto em outras reas do plano do projeto incluindo escopo, custos, qualidade, riscos e a satisfao do cliente. por isso que to importante gerenciar os pedidos de mudanas no cronograma de maneira disciplinada, como descrito no Plano de Gerenciamento de Cronograma e no sistema geral de controle da mudana. Para se manter dentro do plano de gerenciamento do cronograma e o sistema geral de controle da mudana, o Gerente de Projetos deve realizar as seguintes tarefas: Revisar as linhas gerais e os procedimentos para realizar mudanas no

cronograma com a equipe do projeto, como definido no Plano de Gerenciamento do Cronograma e no Sistema de Gerenciamento da Mudana Pedir que todas os pedidos de mudanas no cronograma sejam tratados

formalmente Revisar o progresso da equipe e do trabalho para garantir que nenhuma

mudana de cronograma no autorizada seja feita

Analisando os Pedidos de Mudana no Cronograma importante entender as reais causas dos pedidos para mudanas no cronograma antes de tomar qualquer deciso. A causa mais comum de pedidos de mudanas no cronograma so erros ou omisses durante o planejamento do projeto. J que difcil para a equipe do projeto identificar todas as atividades do projeto e estimar sua durao durante o processo de planejamento, eles descobrem mais sobre o que necessrio para atingir os objetivos do projeto enquanto j esto trabalhando no projeto. Os membros da equipe tem a tendncia de querer revisar seus prazos quando eles so pegos de surpresa com atividades no esperadas e que consomem tempo ou problemas, resultando, assim, em presses para estender o cronograma, reduzir

o escopo, adicionar recursos ou diminuir a qualidade do produto final. Outras fontes de pedidos de mudanas de cronograma so: mudanas nos planos do cliente que precisam ser adiantadas, presses internas, competitivas ou dos clientes para aumentar o escopo do projeto e ocorrncia de eventos importantes e no esperados. Para analisar os pedidos para mudanas no cronograma do projeto, o Gerente de Projetos deve realizar as seguintes tarefas: Identificar a causa raiz do pedido de mudana Estimar os benefcios e custos de realizar a mudana Identificar as implicaes da mudana de cronograma nos outros elementos

do plano do projeto, incluindo escopo, custo e qualidade Estimar o risco envolvido em realizar a mudana Estimar o impacto direto para o cliente Discutir as implicaes de se realizar a mudana com as partes interessadas

mais importantes, incluindo o comprador do projeto e o cliente

Autorizando e Gerenciando Mudanas no Cronograma do Projeto Uma vez que a equipe avaliou completamente os impactos do pedido de mudana do cronograma, a ao deve ser devidamente autorizada e os resultados monitorados. Recursos devem ser mobilizados para fazer a mudana dentro do tempo necessrio e aes futuras podem ser necessrios caso a mudana nas ocorra como planejado. Todo esforo deve ser feito no sentido de manter o cronograma dentro de seus limites atravs de aumento da concomitncia, eliminando ou reduzindo atividades que no agregam valor e buscando alternativas criativas para se realizar o trabalho. Para autorizar e monitorar os pedidos de mudanas no cronograma o Gerente de Projetos deve realizar as seguintes tarefas: Tentar trazer para dentro o cronograma antes de autorizar um extenso

na data de concluso Garantir que a ao proposta devidamente autorizada como foi definido no

Plano de Gerenciamento do Cronograma e pelo Sistema de Controle das Mudanas Garantir que as pessoas responsveis esto preparadas para realizar a

mudana dentro do prazo Pedir feedback ou uma avaliao de desempenho formal do status da

mudana Avaliar o real versus o planejado progresso da mudana Iniciar ao futuras caso necessrio

Atualizando os Documentos Relacionados ao Cronograma

Todas as mudanas no cronograma do projeto deve estar formalmente refletidas nos documentos afetados do projeto, incluindo a EAP, o seqenciamento das atividades, a estimativas de durao das atividades e os planos de gerenciamento dos riscos. No manter os documentos relacionados ao cronograma atualizados pode causar confuso mais a frente do projeto, como tentar comprar o atual progresso do trabalho com o cronograma para refletir base. Os documentos as decises mais devem ser atualizados em relao ao continuadamente recentes

cronograma. Isso fornece uma fonte de informaes atual para todos os envolvidos e cria o histrico do projeto, que ser necessrio para referencias futuras e aprendizado. Para atualizar os documentos relacionados ao cronograma, o Gerente de Projetos deve realizar as seguintes 4 tarefas: Realizar as mudanas de cronograma e designar os responsveis por

atualizar os documentos afetados Usar um controle de verses numrico (1.0, 2.0, 3.0, etc) consistente para

identificar cada atualizao e sua respectiva data Revisar os documentos atualizados para garantir que esto completos e os

distribuir, quando necessrio, para as partes interessadas envolvidas Documentar as causas das mudanas de cronograma, as razes das

decises, alem de outros lies aprendidas com a mudana para compor o histrico do projeto para referencias dentro deste projeto e para futuros projeto.

Lio 15: Planejamento, Garantia e Controle da Qualidade

Objetivos da lio: O glossrio de Gerenciamento de Projetos define qualidade como a soma de todos os atributos ou caractersticas de um item, produto ou servio requerido para satisfazer as necessidades explcitas e implcitas do projeto. Basicamente para atingir a qualidade em projetos necessrio satisfazer as necessidades do cliente. Para satisfaz-las, o Gerente de Projetos deve ser capaz de planejar a qualidade, iniciar a garantia da qualidade e instituir o

controle de qualidade. Para construir projetos que resultem em produtos ou servios de qualidade necessrio entender as necessidades do cliente e trabalhar em cima das mesmas. Qualidade no exceder as necessidades do cliente. Qualidade atender s mesmas. Ao final dessa lio voc deve poder: Identificar o nvel de qualidade requerido pelo projeto e determinar como alcan-lo; Avaliar a performance geral do projeto com frequncia para garantir que ele alcanar o nvel de qualidade exigido; Monitorar os resultados especficos do projeto para determinar se esto de acordo com o nvel de qualidade requerido e iniciar aes para eliminar as causas de performance insatisfatria.

Termos Importantes

ISO 9000; Garantia da Qualidade; Controle da Qualidade; Processos de controle estatstico; Tabelas de dados; Diagrama de causa e efeito; Histogramas; Diagrama e lei de Pareto; Anlise de Tendncia; Grficos de controle; Mtodos de amostragem; Amostragem de atributos; Amostragem de atributos especiais; Amostragem de Variveis; Regra dos sete.

Planejamento da Qualidade O Gerente de projeto deve rever os requisitos do sistema de qualidade de sua organizao e do cliente para definir quais so pertinentes ao projeto. Requisitos como ISO 9001 devem ser documentados e abordados durante o resto do processo de planejamento. Para identificar os requisitos padro de qualidade do projeto, o Gerente do projeto deve: Entender os conceitos de qualidade; Identificar requisitos do sistema de qualidade relevantes; Identificar procedimento chave da garantia e controle da qualidade; Criar definies operacionais; Criar checklists de gerenciamento da qualidade; Elaborar um plano de gerenciamento da qualidade.

Conceitos de Qualidade Qualidade um processo de melhoria continua (CIP). A crescente demanda por qualidade por parte dos clientes faz com que os produtos e servios tenham que ser cada vez mais econmicos e melhores. A melhoria continua da qualidade implica em um mundo que est em constante mudana, portanto qualquer procedimento ou processo que satisfatrio hoje ser insatisfatrio em um futuro prximo. Qualquer processo, aps um perodo de tempo, requer melhorias para que os resultados satisfaam s necessidades do cliente. O Dr Lov Ireland define CIP como uma abordagem holstica focada em 11 princpios: Padro de propsito; Comprometimento em relao qualidade; Foco no cliente e em melhorias; Abordagem processual; Melhoria contnua; Gesto focada em sistemas; Investimento no conhecimento; Trabalho em equipe;

Conservao de Recursos Humanos; Envolvimento total; Comprometimento perpetual.

Esses princpios se complementam e devem ser abordados em toda organizao que deseja implementar o CIP. O conceito de CIP funciona bem com gerenciamento de projetos, pois d suporte aos objetivos da qualidade ao realizar melhorias continuas nos processos e sub processos. Para implementar CIP em um projeto necessrio: Definir e padronizar processos e sub processos; Avaliar processos e sub processos; Melhorar processos e sub processos; Medir processos e sub processos.

A qualidade deve ser planejada no projeto e no inserida no mesmo. O produto ou servio final devem ser discutidos para serem imunes a fatores incontrolveis do ambiente. Dito isso, qualidade mais bem atingida se os desvios dos objetivos estabelecidos sejam minimizados. O custo da qualidade pode ento ser medido como funo do desvio padro e as perdas devem ser mensuradas para todo o sistema. Identificar requisitos relevantes do sistema de qualidade Toda organizao possui padres de qualidade formais e informais. Algumas organizaes estabeleceram sistemas de gesto da qualidade formais para garantir consistncia nos processos e qualidade do produto. Recentemente, os padres de qualidade estabelecidos pela ISO 9000 foram amplamente adotados por empresas para garantir que seus fornecedores esto comprometidos a manterem um sistema de gesto da qualidade rigoroso. Para satisfazer os padres da ISO, a equipe do projeto deve trabalhar com as polticas e procedimentos definidos pela empresa. Tais requisitos abrangem desde documentao e validao da alta direo em cima de qualquer desvio significativo nos procedimentos relacionados qualidade e publicao de resultados de reunies entre a equipe. Esses requisitos devem ser levados em considerao juntamente com quaisquer outros procedimentos de garantia da qualidade do projeto. Para identificar os requisitos de qualidade relevantes, o gerente e a equipe do projeto devem verificar se a organizao adota padres de gesto da qualidade como ISO 9000 e identificar quaisquer outros requisitos relevantes que afetam diretamente o projeto. Identificar procedimentos chave para garantia da qualidade

Os dois tipos de procedimentos relacionados qualidade so garantia e controle da qualidade. A garantia da qualidade foca na preveno de erro ou defeitos, enquanto o controle da qualidade diz respeito a procedimentos para encontrar e eliminar erros. Procedimentos tpicos de garantia da qualidade incluem definies de validao do produto, reviso de desenho, prottipos, experimentos, acompanhamento dos fornecedores e reviso de cdigos. A melhor ferramenta para prover um servio ou produto sem defeitos a preveno e garantia da qualidade. sempre mais caro e demanda mais tempo corrigir erros do que preveni-los. Procedimentos de garantia da qualidade podem ser encontrados na ISO 9000, no sistema de gesto da qualidade da prpria empresa e nos requisitos impostos pelo cliente sobre o projeto. Um elemento chave no plano do projeto, do qual o plano de gerenciamento da qualidade faz parte, identificar e alinhar os procedimentos de garantia da qualidade que possam ajudar a prevenir os erros de acontecerem. Na ausncia de procedimentos pr-estabelecidos, de responsabilidade do gerente do projeto e de sua equipe identificar o mnimo de procedimentos necessrios para garantir a qualidade dos entregveis e processos do projeto. Para identificar procedimentos chave para a garantia da qualidade, necessrio: Definir especificamente a relao entre os procedimentos de garantia da qualidade de sistemas de gesto da qualidade como ISO 9000 e os procedimentos e processos do projeto; Identificar qualquer procedimento de garantia da qualidade relacionado ao sistema de gesto da qualidade da prpria organizao; Identificar qualquer procedimento de garantia necessrio para satisfazer os requisitos do cliente; da qualidade

Identificar qualquer procedimento de garantia da qualidade especfico da indstria ou mercado em questo que a equipe do projeto pode utilizar para melhorar a qualidade dos processos e produto ou servio final.

Identificar procedimentos chaves para controle da qualidade O controle da qualidade diz respeito a procedimento para encontrar e concertar erros, enquanto a garantia da qualidade diz respeito preveno de erros e defeitos. Um controle da qualidade eficaz encontra os erros o mais rpido possvel e evita que os mesmos cheguem ao cliente. Procedimentos de controle da qualidade incluem:

Inspeo e teste do produto final; Isolamento e disposio do defeito; Correo do erro.

Quanto antes o erro for detectado, mais barato e fcil ser para corrigi-lo. Procedimentos de controle da qualidade podem ser encontrados na ISO 9000, no sistema de gesto da qualidade da prpria organizao e nos requisitos do cliente. Um elemento chave no plano do projeto, do qual o plano de gerenciamento da qualidade faz parte, identificar e alinhar os procedimentos de controle da qualidade que possam identificar e corrigir os erros que acontecerem. Na ausncia de procedimentos pr-estabelecidos, de responsabilidade do gerente do projeto e de sua equipe identificar o mnimo de procedimentos necessrios para testar e corrigir a qualidade do projeto. Para identificar procedimentos chave para o controle da qualidade, necessrio: Definir especificamente a relao entre os procedimentos de sistemas de gesto da qualidade como ISO 9000 e os procedimentos de controle da qualidade e processos do projeto; Identificar qualquer procedimento relacionado ao sistema de gesto da qualidade de controle da qualidade do projeto da prpria organizao; Identificar qualquer procedimento de controle da qualidade do projeto necessrio para satisfazer os requisitos do cliente; Identificar qualquer procedimento de controle da qualidade do projeto especfico da indstria ou mercado em questo que a equipe do projeto pode utilizar para melhorar a qualidade dos processos e produto ou servio final.

Criar definies operacionais Como tendemos a assumir que todos entendem e interpretam os termos e conceitos da mesma forma, muita confuso acaba acontecendo nos resultados do projeto quando a terminologia do projeto indefinida. As pessoas tendem a terem interpretaes distintas de termos e agem em cima delas. Sendo assim fica muito difcil seguir as aes como esperado ou cobrar das pessoas se no h um padro de qualidade claramente definido. Um tpico exemplo quando os gerentes de projeto requerem feedbacks freqentes

dos membros da equipe. Freqente semanalmente, mensalmente, etc.

pode

querer

dizer

todo

dia,

Para operacionalizar os termos e prevenir rudos na comunicao e confuso necessrio criar as definies operacionais. Para cri-las, necessrio: Identificar a terminologia utilizada na documentao do projeto que pode ser interpretada; Chegar a um consenso sobre definies operacionais para todos os termos; Elaborar um glossrio documentos do projeto; dos termos relevantes em todos os

Buscar clareza nas comunicaes formais e informais entre a equipe e qualquer outro stakeholder do projeto.

Criar checklists de gerenciamento da qualidade Uma atividade, processo ou entregvel importante que requer consistncia entre toda a equipe do projeto pode ser simplificado com a elaborao de um modelo ou checklist. Checklists ajudam a identificar os elementos chave requeridos para completar com satisfao e so uma boa maneira de definir atividades e entregveis. A utilizao de checklists podem fornecer benefcios como: Criar consistncia; Criar documentos rastreveis requeridos pela ISO 9000 e processos de auditoria do cliente; Criar consistncia entre a equipe sobre o que esperado; Aumentar a eficcia dos processos de treinamento para novos colaboradores; Auxilia na preveno de erros e esquecimentos.

Para criar checklists de gerenciamento da qualidade, necessrio: Identificar processos, atividades e entregveis chave que requerem consistncia na sua execuo; Definir os passos necessrios nas atividades e processos ou os atributos dos entregveis; Criar checklists de fcil uso e distribuir aos membros e stakeholders relevantes para reviso e comentrios;

Revisar as checklists como necessrio e distribuir como caractersticas formais do projeto para todos que sofrero impacto com o mesmo.

Elaborar um plano de gerenciamento da qualidade O plano de gerenciamento da qualidade simplesmente aplicar as polticas e procedimentos relevantes para a qualidade do projeto. O plano define como as polticas e procedimentos sero implementados para gerenciar a qualidade ao longo do projeto. Ele deve mencionar a garantia e controle da qualidade e aspectos de melhoria, como discutidos anteriormente, pois ser utilizado como um guia para garantir e controlar a qualidade durante a execuo e controle do projeto. O plano deve mencionar todos os aspectos importantes de como a qualidade dos processos e entregveis do projeto devem ser gerenciados. Para elaborar o plano de gerenciamento da qualidade do projeto necessrio: Procurar ajuda e conselho da equipe responsvel pela qualidade na organizao; Revisar o plano de gerenciamento da qualidade de outros projetos similares que j foram realizados; Determinar como os procedimentos de controle e garantia da qualidade, identificados anteriormente devem ser aplicados nas atividades processos e entregveis do projeto; Definir critrios para a execuo efetiva das principais atividades, processos e entregveis do projeto; Definir responsabilidades para todos os aspectos do plano de gerenciamento da qualidade; Identificar ou incluir qualquer checklist ou modelo que deve ser usado pelos membros da equipe; Definir como o projeto ser auditado para garantir o alinhamento com o plano de gerenciamento da qualidade.

Garantia da Qualidade A equipe do projeto garante a qualidade do mesmo conduzindo as verificaes definidas no plano de gerenciamento da qualidade. Indivduos alocados como os donos de qualidade devem conduzir as verificaes no incio de cada nova tarefa. Todos os resultados devem ser encaminhados ao Gerente de projeto para que aes preventivas e corretivas sejam

planejadas como requerido. Para revisar os entregveis do projeto antes de implement-los, necessrio:

Revisar os entregveis antes da implementao; Antecipar desvios de qualidade e tomar aes preventivas; Testar os processos e produtos do projeto antes de implant-los; Requerer validao prvia e feedback do cliente.

Rever entregveis do projeto antes da implementao Documentos relativos ao desenho e planejamento dos entregveis do projeto devem ser revistos antes de implementados para prevenir erros de causarem um impacto negativo nas atividades conseguintes. Erros na especificao e desenho do produto, cdigo de computao, e planejamento de testes, por exemplo, podem causar problemas significativos quando desenvolvendo ou testando o produto. Muitos desses problemas potenciais podem ser identificados antes da implementao atravs de revises e inspees. Tambm verdade que quanto antes o problema for identificado, mais barato e fcil concert-lo. Para revisar os entregveis de um projeto antes de sua implementao, necessrio:

Revisar o plano de gerenciamento da qualidade com a equipe do projeto para confirmao das atividades de garantia da qualidade; Assegurar que as atividades de garantia comprometem o cronograma do projeto; Revisar os entregveis crticos do documentos antes de implement-los; projeto da qualidade no

assim

como

seus

Identificar potenciais problemas e aes corretivas; Designar responsabilidade de mudana dos entregveis para seus autores originais; Distribuir documentos afetados. modificados para todos os stakeholders

Antecipar desvios de qualidade e tomar aes preventivas Desvios na qualidade tanto do projeto quanto nos processos do mesmo podem ser prevenidos se detectados com antecedncia. Um sistema de alerta prvio deve ser usado para identificar os desvios e tomar aes preventivas em tempo hbil. Uma abordagem elaborar um sistema em que boletins sejam enviados sempre que um problema em potencial surgir. Essas excees devem ser tratadas com as aes corretas para que no

hajam desvios. Aes preventivas devem ter seus dias de incio e fim indicados e devem ser monitoradas por um responsvel apenas. Para antecipar desvios de qualidade e tomar aes preventivas, necessrio: Revisar o plano de gerenciamento da qualidade para adicionar procedimentos de garantia da qualidade que se vejam relevantes; Antecipar e documentar as excees; Planejar aes para prevenir que desvios ocorram; Monitorar as aes preventivas para garantir a resoluo em tempo hbil.

Testar os processos do projeto e produto antes de execut-los Os processos do projeto e relacionados ao produto so comumente desenvolvidos e implantados para uso sem serem devidamente testados ou verificados. Processos problemticos podem causar confuso desnecessria e adicionar ao tempo e custo requerido pelo projeto. Depender exclusivamente do email para realizar a comunicao durante o projeto tambm pode causar problemas se os membros da equipe utilizarem plataformas ou servidores distintos. Os processos chave nos quais a equipe depende para alcanar os objetivos do projeto devem ser identificados e testados antes de implementados. Para testar os processos antes de implement-los, necessrio: Identificar os processos do projeto e produto que devem ser testados; Verificar a performance desses processos em outros projetos para identificar foras e fraquezas; Conduzir testes funcionamento; dos processos chave para verificar seu

Identificar os problemas e limitaes dos processos; Realizar aes corretivas para melhor-lo.

Solicitar a validao e feedback prvio do Cliente Como quem define a qualidade o cliente, uma boa idia pegar seu feedback sobre os entregveis do projeto o quanto antes. Isso permite o alinhamento das expectativas e a possibilidade de identificar desentendimentos antes que muito tempo ou recursos sejam utilizados. prefervel receber feedbacks negativos o quanto antes, pois as mudanas

podero ser realizadas com mais facilidade e sem sacrificar o escopo, qualidade, tempo ou oramento do projeto. Para receber o feedback do cliente, o Gerente pode utilizar tcnicas como mandar boletins informativos, mostrar o que foi feito e quais so os prximos passos para o cliente, e o desenho de prottipos simplificados. Para solicitar a validao e feedback prvio do cliente, necessrio: Identificar os mtodos e oportunidades para conseguir feedback prvio; Requerer a cooperao do cliente para a reviso dos entregveis do projeto; Planejar e estruturar como ser o feedback do cliente para passar o que til para a equipe; Conduzir as revises desentendimentos; e identificar problemas em potencial e

Trabalhar junto ao cliente modificaes pertinentes.

para

desenvolver

as

solues

Controle da Qualidade O Gerente do Projeto pode implementar um plano de teste e validao para garantir que cada parte do projeto performe como requerido pelo cliente. Um bom objetivo para qualquer projeto testar todos os produtos e servios antes de entreg-los ao cliente. O plano de gerenciamento da qualidade deve listar todos os equipamentos e performance requerida dos materiais e os testes requeridos para test-los. A equipe do projeto pode identificar e implementar aes corretivas e emitir seus relatrios para resolver qualquer problema ou erro detectado durante os testes. Mudanas podem ser realizadas pelos donos das atividades e submetidos a testes para aceitao final. O processo de controle de qualidade requere: Comparar os resultados do trabalho com o plano de gerenciamento de qualidade; Analisar desvios do padro estabelecido; Tomar aes corretivas; Documentar as aes e atualizar os planos.

Comparar os resultados do trabalho com o plano de gerenciamento de qualidade

Os processos e seus resultados devem ser constantemente monitorados pra garantir o alinhamento com os padres de qualidade apresentados no plano de gerenciamento da qualidade. O processo ideal de controle da qualidade realizado ao monitorar os processos nos quais os entregveis so desenvolvidos e identificar desvios antes que haja um impacto negativo no projeto. Dessa forma, desvios da qualidade ou defeitos sero evitados ou minimizados. A segunda melhor forma de inspecionar e avaliar os entregveis do projeto avaliar os prprios entregveis e identificar desvios ou defeitos. Embora as inspees no possam prevenir os defeitos, elas podem identific-las rapidamente e levar aes corretivas em tempo hbil. Vrias tcnicas utilizadas para controlar a qualidade tambm podem ser utilizadas para identificar desvios nos processos do projeto incluindo tempo e custo. Para monitorar os processos e resultados, necessrio: Revisar o plano de gerenciamento da qualidade para identificar as variveis chave do projeto e produtos para monitorar; Implantar mtodos apropriados de monitoramento para as variveis identificadas; Monitorar as variveis para controle e conformidade com os padres de qualidade; Identificar as variveis que esto tendendo a fugir da conformidade; Inspecionar os resultados de trabalho e entregveis do projeto para verificar conformidade com os padres de qualidade definidos; Identificar qualquer resultado de trabalho e entregveis que no esto alinhados com os padres de qualidade.

Mtodos de monitoramento por processos estatsticos de controle Mtodos de controles estatsticos representam a medio da variabilidade do produto com relao a uma especificao ou requerimento. Se o produto excede os limites normais de aceitao, ele rejeitado. Se o produto atende as especificaes ele passa ou aceito. Diferentes mtodos de controle estatsticos da qualidade so: Tabela de dados So formas de representar dados coletados durante o estudo do processo. Elas organizam e apresentam os dados de forma lgica e formato interpretativo. A tabela a seguir um exemplo de uma tabela de dados utilizada para comparar amostrar de materiais entregues pelos fornecedores para uma fbrica de montagem de foguetes:

Categorias Verificadas Danos martimos Material entregue atrasado Partes que falharam testes Soma Ll Lll A lll

Fornecedores B lll lll C lll lllll D

Soma

11 16

lllll

lll

ll

ll

11

10

35

Diagrama de causa e efeito Tambm chamados de diagrama de espinha de peixe, essa ferramenta utilizada para ilustrar a raiz do problema. Os passos para um diagrama de causa e efeito so: Identificar o problema; Alocar membros da equipe para realizar a anlise; Desenhar o problema e seta principal; Identificar causas do defeito e listar abaixo de cada problema utilizando tcnicas de anlise; Identificar aes para corrigir o problema.

O diagrama de causa e efeito uma representao grfica dos itens listados. Ele ideal para ser utilizado em brainstorms j que todos os membros conseguem ver as relaes. Ele pode estimular e organizar as idias dos membros que participam do brainstorm. Essa ferramenta tambm pode documentar o nvel de entendimento e possibilita um timo modelo para expandir os pensamentos do grupo. Ele permite a equipe a explorar um raio abrangente de reas incluindo a relao dos problemas para o mesmo processo. Os principais passos para se construir um diagrama de causa e efeito so: Identificar o problema (efeito); Identificar as causas principais;

Identificar possveis sub-causas que contribuam para as causas principais; Desenhar o diagrama de causa e efeito completo; Analisar as causas e tomar as aes apropriadas.

O diagrama de causa e efeito abaixo demonstra os motivos para o turnover de uma empresa genrica.

Histogramas uma ilustrao grfica de uma variedade de dados como uma distribuio de suas freqncias. um diagrama de barras verticais em um grfico mostrando a freqncia de um evento ao longo do tempo. Essa ferramenta auxilia na avaliao da alocao de um recurso. Muitos softwares de gerenciamento de projetos (por exemplo o Project) utilizam histogramas para mostrar a alocao de recursos. Os histogramas so valiosos para avaliar atributos de qualidade tanto nos dados (passou/falhou) quanto variveis (dados de medio). Ele possibilita uma visualizao rpida de um dado em um curto espao de tempo e til para entender as freqncias relativas ou freqncias de um dado e como ele distribudo. Tambm utilizado para aprender sobre a localizao, distribuio e forma de um dado. Diagrama de Pareto Essa ferramenta foi desenvolvida por Vilfredo Pareto que, no fim de 1800, disse que 80% da riqueza da Itlia se encontrava nas mos de 20% da populao. Duran utilizou essa teoria para formalizar o princpio de Pareto. Isto , 20% das atividades representam 80% dos problemas. Existem trs tipos de anlises Pareto: Bsica Identificar os contribuintes vitais para a maioria dos problemas de qualidade de qualquer sistema;

Comparativa Compara opes de programas ou aes; Com pesos Fornece uma medida de importncias a fatores que podem no parecer significativos primeira vista como tempo, custo e impacto.

O diagrama de Pareto utilizado para: Identificar no-conformidades; Determinar freqncias para vrias categorias; Listar no-conformidades em ordem decrescente; Calcular a porcentagem de freqncias para cada categoria e freqncia cumulativa.

Anlise de tendncias Esses diagramas mostram um mtodo estatstico de determinar a equao que melhor se encaixa com o grfico dos dados. O processo tende a qualificar os dados, prover a equao e a linha de tendncia dos mesmos. Anlise de tendncia utilizada para determinar a relao entre dois ou mais dados correspondentes. Os dados so plotados em um sistema axial XY para mostrar a correlao. Essa ferramenta pode auxiliar na previso do que ocorrer. Grficos de controle Esses grficos so utilizados para focar na preveno de um problema ou invs de identificao ou rejeio. Grficos de controle so normalmente utilizados na distribuio normal.

1 = 68.26% 2 = 95.46% 3 = 99.73%

Baseado nas especificaes e custos do limite superior de controle (UCL) e limite inferior de controle (LCL) da variao aceitvel, um grfico de controle pode ser elaborado. A UCL e LCL so representados por 3 anlise de grficos de controle determina se um processo est estvel. . A

Mtodo de amostragem amostragem a forma de determinar o valor de um produto ou servio quando ele no prtico de ser examinado como um todo. Para garantir que um produto atinge suas especificaes, ele deve ser inspecionado. 100 por cento de inspeo pode ser muito caro e demandar muito tempo e, devido a erros humanos, no pode ser 100 por cento confivel. Por isso diferentes tipos de amostragem foram desenvolvidos. Lew Ireland, em Quality Management for Projects and Programs diz que

existem algumas maneiras de se definir qual o tamanho da amostragem necessria. Seguem as quatro formas bsicas de se realizar amostragem: Amostragem por aceitao um conceito mais do que um mtodo de amostragem. Ele assiste na determinao de conformidade do produto em relao a suas especificaes. Estabelecer inspeo e testar as especificaes do produto a forma de faz-lo. A inspeo do produto pode ser visual, eletrnica, sob teste de stress, destruio de amostra, teste de temperatura, etc. importante notar que a especificao da inspeo deve incluir como a amostra ser escolhida. A determinao de padres de inspeo e teste so estabelecidos para qualificar lotes de amostras. Esses padres devem concentrar nos valores paramtricos desejados. Amostragem por atributos ocorre quando a gerncia decide quantos defeitos de atributos do produto (peso, tamanho, funes, etc.) so aceitveis antes do lote ser rejeitado. Uma amostra randmica escolhida e o inspetor procura uma ou mais falhas de atributos para inspecionar. Os atributos selecionados so considerados crticos e sabe-se que falharam no passado. Se o nmero pr-definido de rejeio for alcanado antes do fim do lote, o mesmo rejeitado. Os produtos sob inspeo so classificados em sim/no, defeituoso/nodefeituoso, correto/incorreto, etc. Esse mtodo de amostragem utilizado para defeitos visuais, de fabricao, dimenses incorretas, defeitos no material, marcao, empacotamento, entre outros. As vantagens desse mtodo so que ele mais simples e menos caro do que os outros. As desvantagens so que ele requer um grupo maior de amostragem para que a quantidade desejada de informao seja igual ao de amostragem por variveis. Isso se torna importante quando as unidades de amostragem so caras em tempo ou dinheiro. Amostragem por atributos especiais similar amostragem por atributos, mas envolve o uso de trs tipo de amostragem: o Mtodo continuo onde unidades so produzidas e submetidas consecutivamente inspeo na ordem que so produzidas. Isso realizado quando a armazenagem inadequada ou no prtica para acumular produto em lotes para inspeo; Mtodo de cadeia onde um lote de produto manufaturado para outro produto. A amostragem ocorre durante todo o processo at que o produto final seja produzido. Esse mtodo utilizado quando h um bom histrico de qualidade e o tamanho da amostragem relativamente pequeno; O mtodo Skip-a-lot (pule o lote) permite a reduo no custo da inspeo em detrimento da qualidade da inspeo. O preo

pago por pular um lote de inspeo o risco de aceitar um produto com baixa qualidade. Esse mtodo utilizado quando o processo de fabricao j atingiu um nvel maduro. Amostragem de variveis envolve uma varivel que caracterstica ou propriedade que pode ser mensurada e expressa em forma contnua (ex. tempo, comprimento, peso). A inspeo por variveis uma inspeo na qual a qualidade da caracterstica de cada unidade do produto medida e aceita ou rejeitada dependendo da mdia e desvio padro apresentados pelos produtos. A amostragem por variveis tem a vantagem de medir a qualidade em uma escala continua ao invs de sim/no. Pelo fato de fornecer informaes mais detalhadas sobre o produto, os lotes so menores. Esse mtodo considerado o mais eficaz, mas requer uma inspeo com uma equipe de grande qualidade tcnica e caractersticas padres para serem avaliadas.

Separado dos mtodos de amostragem comuns a Regra dos Sete. Essa regra auxilia na determinao controle de um. Se uma de sete amostras apresentam defeitos fora do padro, o processo est fora de controle. A probabilidade dessa regra falhar de aproximadamente 1,56%. Analisar desvios de padro Aps a identificao de desvios nos produtos ou processos, eles devem ser analisados para determinar a raiz do problema. importante tomar tempo para identificar a real causa, ao invs de apenas os sintomas, antes de tomar as aes corretivas. No caso de atraso de cronograma, por exemplo, tomar a ao corretiva apropriada vai depender se a causa do problema foi dificuldades tcnicas ou simplesmente otimismo na estimativa de tempo necessrio para realizar o processo ou elaborar o produto. H uma variedade de ferramentas que podem ser utilizadas para identificar as causas (como as supracitadas). Para analisar os desvios do padro da qualidade, necessrio: Obter todos os dados relevantes para o desvio; Organizar os dados com as ferramentas que vo fornecer maior entendimento; Organizar uma reunio envolvidos com o desvio; com a equipe ou outros diretamente

Aplicar as ferramentas mais apropriadas e tcnicas de discusso em grupo para identificar as causas do problema; Identificar as causas mais provveis.

Tomar aes corretivas Aes corretivas devem ser definidas e implementadas assim que a causa mais provvel do desvio de qualidade seja identificada. As aes devem ser realizadas para reduzir os impactos negativos imediatos do desvio e prevenir sua recorrncia. Todas as aes devem ser discutidas com os stakeholders afetados e implementadas de acordo com o plano de gerenciamento da qualidade e os procedimentos delineados no processo de controle de mudanas. Para tomar aes corretivas necessrio: Identificar aes potenciais para corrigir e prevenir a recorrncia dos desvios de qualidade; Decidir nas aes que melhor corrigiro o problema; Discutir essas aes com os stakeholders que sero afetados pelas mesmas; Designar um membro da equipe responsvel pelas aes; Tomar as aes corretivas e monitorar os seus resultados; Tomar as aes corretivas que surgirem a seguir se necessrio.

Documentar aes e atualizaes nos planos Todas as aes tomadas em resposta ao desvio da qualidade devem ser documentadas como parte dos arquivos do projeto. Alm disso, o plano de gerenciamento da qualidade deve ser atualizado, assim como o cronograma e plano do projeto, se necessrio. Aes corretivas devem incluir as novas atividades a serem inseridas no projeto da mesma forma que as atividades iniciais foram definidas, seqenciadas e tiveram seus tempos estimados. Para documentar as aes e atualizar o plano do projeto, necessrio: Definir atividades envolvidas com as aes corretivas programadas; Identificar as dependncias e seqenciamento das aes corretivas; Estimar a durao das aes corretivas; Estimar os impactos e recursos adicionais requeridos pelas aes corretivas; Atualizar o cronograma do projeto e documentos relacionados s aes corretivas com todas as estimativas; Atualizar o plano de gerenciamento da qualidade do projeto.

Lio 16: Integrando os Principais Processos de Planejamento

Objetivos da lio:

Integrar o processo de unir pessoas, atividades e outros para performar com eficcia. Integrar os principais processos de planejamento envolve compilar os resultados de todos os processos de planejamento e uni-los com consistncia e coerncia em um documento: o Plano de Projeto. Nessa lio, analisaremos como os processos interagem entre si e com processos de outras reas. Cada processo pode envolver esforo de uma ou mais pessoas ou pequenas equipes baseado nas necessidades do projeto. Ao final da lio voc deve ser capaz de: indica. Compilar os resultados dos processos de planejamento do projeto,

unificando-os em um documento consistente e coerente; Executar o projeto ao seguir o plano do projeto e as atividades s quais ele

Termos Importantes Integrao; Reunies de Incio de Projeto; Desenvolvimento de Equipe; Distribuio de Informao; Assegurar a Qualidade; Solicitao; Seleo de Fonte; Administrao de Contrato; Verificao de Escopo.

O Gerente do Projeto inicia a integrao do projeto ao compilar todos os documentos do planejamento em um plano de projeto. A equipe do projeto revisa os documentos para verificarem sua totalidade, preciso e conformidade, corrigindo qualquer problema encontrado. Todos os envolvidos no planejamento do projeto devem identificar e eliminar documentos duplicados e assegurar que tudo o que

requerido pelo projeto est adequadamente definido.

Por vezes, uma parte do

plano pode estar cobrindo uma informao similar de outra parte. Isso deve ser identificado e coordenado para garantir a consistncia dos registros. Para integrar os resultados dos processos de planejamento, necessrio: Coletar todos os documentos de suporte e do planejamento do projeto; Revisar todos os documentos para garantir sua totalidade, preciso e

consistncia; Garantir o alinhamento com as polticas organizacionais e restries

impostas no projeto; Identificar e solucionar qualquer problema com os documentos de

planejamento; Atualizar os documentos de planejamento afetados pela reviso.

O Gerente do Projeto o integrador que comunica o dia de incio da execuo por toda a organizao. Ele ou ela notifica gerentes funcionais sobre o incio do projeto e requere que todos os membros saibam da data. Os membros da equipe do projeto devem comparecer reunio de incio de projeto. Para marcar o incio do projeto, a equipe deve revisar seu papel e responsabilidades, e o Gerente do Projeto deve verificar que todos os membros so capazes, disponibilizam de tempo e querem aceitar e completar suas atribuies de acordo com o plano. integrar todas as atividades do projeto, o Gerente do Projeto deve: Garantir a validao do plano do projeto para iniciar as atividades; Executar as atividades do projeto como planejado; Garantir que as atividades do projeto so executadas como planejado; Identificar alteraes necessrias no plano do projeto. Para

Garantir a validao do plano do projeto para iniciar as atividades Essa ao representa a transio crtica entre o planejamento e a execuo do projeto que todos enfrentam. ser posto em prtica. qualquer outra Durante o planejamento do projeto, muito assumido sobre a disponibilidade de recursos e nesse momento que isso tem que Muitas vezes alguns membros da equipe ainda esto durante o tempo de execuo do projeto. alocados em outros projetos que j deveriam ter terminado, ou esto alocados em atividade responsabilidade do Gerente do Projeto, com o auxilio do patrocinador, garantir que todos os recursos esto livres de outras responsabilidades para executar suas atividades do projeto dentro do cronograma. A transio do planejamento para a execuo tem um impacto direto na viabilidade da execuo do projeto dentro do prazo. O Gerente do Projeto tambm responsvel por garantir que todos os recursos necessrios estejam disponveis para a equipe do projeto realizar seu

trabalho de forma eficiente e eficaz. requerem:

A autorizao e inicializao do projeto

Formalmente comunicar o incio da execuo do projeto para os membros,

gerentes funcionais e stakeholders mais importantes; Coordenar com os gerentes funcionais a alocao dos seus colaboradores

para iniciarem suas atividades relativas ao projeto; Trabalhar individualmente com os membros da equipe para garantir que eles

entenderam o cronograma e comecem imediatamente as suas atividades.

Executar as atividades do projeto como planejado responsabilidade de cada membro da equipe do projeto realizar as suas atividades e cumprir suas responsabilidades como planejado. seus compromissos. Como a equipe auxiliou no planejamento do projeto, responsabilidade deles assumir todos os Apesar de sempre haverem motivos para as coisas no acontecerem como planejado, o sucesso do projeto depende de cada membro da equipe fazer o que esses se comprometeram a fazer. Tambm responsabilidade de cada membro da equipe coordenar de perto as suas atividades independentes com as dos outros membros da equipe. imediatamente procurar ajuda do Gerente do Projeto. conflitos mais difceis. Para executar as atividades do projeto como planejado, necessrio: Revisar o planejamento e elaborar um plano individual de execuo para Quando algum membro da equipe no consegue executar alguma atividade, ele deve O Gerente do Projeto tambm pode solicitar a assistncia do patrocinador para resolver os problemas e

cada membro da equipe; Resistir a tentao de atrasar o trabalho planejado com a esperana de

recuperar o tempo perdido depois; Trabalhar em conjunto com os gerentes funcionais para superar conflitos

entre as atividades do projeto e das funes normais do colaborador; Trabalhar proativamente com todos que so responsveis por completarem

o trabalho; Informar ao Gerente do Projeto sobre problemas que esto limitando a

performance da equipe e sugerir alternativas para corrigir os erros.

Garantir que as atividades do projeto so executadas como planejado O papel do Gerente do Projeto monitorar o projeto e garantir que os membros da equipe realizem seu trabalho como planejado. Apesar do Gerente do Projeto s vezes no ter autoridade direta sobre alguns membros da equipe,

responsabilidade dele influenciar as pessoas que esto trabalhando para ele e ajud-los a superar os problemas que eles possam enfrentar. Membros da equipe assumem avanos dos quais eles dependem e se surpreendem quando no recebem os insumos chave necessrios do Gerente como do indica , o cronograma. portanto, garantir Outra uma responsabilidade Projeto

coordenao conforme entre os membros da equipe, especialmente os que dependem de outros. Para garantir a execuo das atividades do projeto como planejado, necessrio: Monitorar a performance dos membros da equipe para identificar qualquer

barreira que possa afetar a execuo das atividades do projeto; Trabalhar junto com os gerentes funcionais para resolver qualquer problema

de superalocao; Coordenar as atividades interdependentes entre os membros da equipe; Prover coaching e assistncia aos membros da equipe sempre que

necessrio.

Identificar necessidade de mudanas no Plano do Projeto Alteraes no plano do projeto so inevitveis durante a execuo do mesmo. As circunstncias mudam constantemente e imprevistos requerem reconsiderar o que foi assumido durante o processo de planejamento do projeto. responsabilidade da equipe e Gerente do projeto tentar contornar esses problemas e minimizar as mudanas no plano. Porm igualmente importante que os Esses sinais de alerta devem ser membros da equipe alertem o Gerente do Projeto sobre fatores que possam condenar o alcance dos objetivos do projeto. apresentados no processo de boletim de performance, discutido na lio 7. Para identificar as mudanas no plano do projeto, necessrio: Constantemente comparar a execuo do projeto com o plano do mesmo; Procurar contornar os problemas e minimizar as alteraes do plano; Alertar o Gerente do Projeto imediatamente aps a identificao de fatores

que podem condenar o alcance dos objetivos do projeto; Procurar identificar as causas e potenciais solues para problemas que

possam surgir devido alterao no plano do projeto; Incluir potenciais alteraes no plano do projeto.

Processos facilitadores Os sete processos que do suporte e so executados durante a execuo do plano do projeto so: Desenvolvimento de equipe;

Distribuio de informao; Assegurar a qualidade; Solicitao; Seleo da fonte; Administrao de contrato; Verificao de Escopo.

Cada um desses processos, j foram, ou sero discutidos ao longo das lies.

Lesson 17: Organizational Planning

Lesson Performance (Learning) Objectives In today's fast-paced business environment, multiple projects are a reality, and most employees are required to simultaneously handle several projects. It's not enough to just to schedule multiple projects without regard to the interconnecting impacts. What is common to all projects of any given organization are that they must utilize the same resource pool. Too often these resources are overallocated due to poor organizational planning. By the end of the lesson you should be able to: Explain the different uses of organizational templates Understand the uses of human resource practices Explain organizational theory Develop a strategy for use of stakeholder analyses

Important Terms Projectized Organizations Functional Organizations Matrix Organization Project Coordinator Project Leader Responsibility Assignment Matrix Project Organization Chart

Overview Industry has come to the same conclusion as what the military realized 30 years ago. The use of traditional organizational hierarchies tends to be slow, inflexible, and fail to provide a focus for the mission at hand. Barriers commonly exist in traditional organizations. This stifles the horizontal flow of activities required when projects are undertaken. Inadequate delegation of authority and responsibility to support project activities becomes a common problem in the fast pace of today's business world. Just as the military realized that task organizing for the mission (project) at hand was the most effective use of resources, so too has industry moved to a highly flexible and responsive paradigm of organizational planning. Organizing for project involves the full spectrum of organizational theory. Some projects may do well in a hierarchical structure with a functional manager or team lead managing the project. Some projects may use a weak matrix where a project administrator assists in the requisite project management activities. Some projects may use a balanced matrix with a project coordinator providing some project management. Some projects may even be structure as a strong matrix with the project manager responsible for the project's success. And, some project can even go so far as being projected where all resources work for the project manager or program manager 100% of the time. Each organizational structure has its advantages and disadvantages based on the nature of the project. Whatever structure is finally decided, organizational planning requires: o o o o o o Identifying the organizational constraints and limitations Determining the project organizational structure Assigning the roles and responsibilities of team members Creating the staffing plan Creating the project organization chart Documenting the supporting detail

Identifying Organizational Policies, Constraints, and Limitations Although creating the organization structure for the project is one of the first planning tasks, the project manager does not have much input in making this decision. The way a project is organized is usually influenced, by the policies, systems, and culture of the larger organization. The project manager must understand the organizational context in which the project will function and determine how those factors will affect and limit the teams options. Identifying organizational constraints and limitations requires: Determining how much latitude is allowed in organizing the project Defining the role of the project manager, which can range from a more

passive "coordinating" to a more assertive commanding approach

Understanding the constraints placed on the project by management and

other key stakeholder organizations Understanding the pertinent human resource policies, procedures, and

guidelines Assessing the availability, timing, skills and capabilities of the people to be

assigned to the project Determining the Organizational Structure The project manager and sponsor working together must structure a project organization that best facilitates the accomplishment of project objectives. This selected organizational approach depends on the needs of the project and the management style of the larger organization. The extent of authority top management is willing to delegate to the project manager will in large part dictate the organizational environment. For example, in a projectized structure, the project manager typically exercises great autonomy over project decisions and has direct managerial responsibility over the team. On the other hand, the project manager in a functionally based organization serves as a coordinator or administrator and possesses little formal decision making authority. Examples of the different project organization types and the influences of these structures are show below: When comparing functional organizations versus projectized organizations one must weigh the advantages and disadvantages to the project. The disadvantages of functional organizations include a limited span of control, the PM has no formal authority, and team members tend to place more emphasis on functional specialty to the detriment of the overall project. The advantages of functional organizations are they easier to manage the specialists if grouped together and supervised by individuals possessing the same skills and experiences. Functional organization centralizes similar resources and provides mutual support by physical proximity while clearly defining career paths for the participants. On the other hand, in a projectized organizational structure the PM has total authority, and retains flexibility to acquire resources needed for project from within or without the parent organization. The matrix organization falls between the functional and Reference: Guide to the PMBOK, PMI projectized organizations and varies on being a weak to being a strong matrix as the chart above depicts. A matrix organization maintains functional (vertical) lines of authority with horizontal structure for projects designed to work with all functional departments that support the project while reducing or eliminating duplication of effort designed to manage several projects simultaneously without sufficient resources to totally projectize. A few variations of the project manager's position requires definition here depending on the type of organizations. As depicted in the chart, the Project Leader (PL) is usually a functional position but can also be a weak matrix position that acts as staff assistant to department manager. The PL has little authority and makes few

decisions. They make recommendations to the department manager, regarding the project, for decision. Their primary responsibilities include timely arrival of parts/materials, completion of tasks and communication of decisions to people working on the project and to the department manager. The PL position requires powers of persuasion to effect results. They are used in functional organizations on projects of low importance and costs. Project Coordinator (PC) has authority to assign work and acts as

communications channel between upper management and the team. The functional manager still has authority for merit reviews. This position presents a high conflict situation and is used on small to medium projects with lower levels of importance to the parent organization. In addition, most organizations will include a "core team" and an "extended team." Core team members are assigned to the project as a primary responsibility and are held accountable for the success of the project. A typical core team for a product development effort will include members from marketing, engineering, manufacturing, quality, and technical support. The number of core team members will vary according to the size and complexity of the project, but is normally kept between eight and twelve. Extended team members are those who provide valuable support services to the core team but do so as one of their many responsibilities. Examples might include people who are assigned to provide recruitment or product documentation services to the core team. The number of extended team members can vary widely. It is the project manager's responsibility to create a core team with each member being responsible for leading and managing the efforts of extended team members. Determining the project organization structure requires: Assessing the various organizational alternatives Identifying the best approach to meet the project requirements Evaluating the organizational policies, constraints, and limitations Determining the optimal structure within the policies, constraints, and

limitations Discussing the recommendation with the project sponsor and deciding the

best structure Assigning the Team Members Roles and Responsibilities One of the keys to managing projects successfully is assigned accountability. All members of the core and extended project teams must be clear about what their responsibilities are, what they are expected to deliver, and how their performance on the project will be evaluated. Project assignments, which should be shared equitably, are usually made according to the knowledge, experience, and interest levels of the individual team members. Personal commitment by all team members to fulfill their project responsibilities is required for the project to succeed. Commitment can be obtained in a variety of ways, but having the project manager spend the time to explain the project requirements and getting people to

buy-in to their responsibilities are always important ingredients. The project manager should create a Responsibility Assignment Matrix (RAM) to summarize the team members responsibilities in terms of the deliverables defined in the WBS. This will also help identify any deliverables without owners. An example of a Responsibility Assignment Matrix is shown below: Reference: Guide to the PMBOK, PMI. As individual responsibilities are finalized, the matrix should be updated until all WBS deliverables have assigned owners. The same approach can be used to show ownership for key project activities. Defining roles and responsibilities requires: Determining the most appropriate people on the team to be responsible for

all WBS deliverables and key activities on the activities list Working with each team member to understand what is involved with each

assignment Balancing the workload equitably among team members Confirming each team members commitment to fulfill their responsibilities Developing a Responsibility Assignment Matrix (RAM) to delineate team

members' assignments Identifying any deliverables or activities that are not assigned and ensure

they are accepted by the appropriate team members Identifying key staffing risks due to lack of needed skills or staffing levels Procuring the needed skills or staffing levels as needed

Creating the Staffing Plan The staffing requirements must be synchronized with the preliminary results from the scheduling activities in the Schedule Development process to create a "time-phased" staffing management plan. This plan shows when specific resources are required throughout the life of the project. Projects typically start out with a small "core-team" of people who perform the initial project definition and planning activities and expand as the project progresses from planning to execution. In addition, different phases of the project will also require different skills and functions to get involved. For example, engineering will have the greatest involvement during product design and development, whereas the quality function will get more involved during product internal/external testing and field organizations have primary responsibility for product installation and service. The project manager uses a time-phased staffing plan as a planning and communications tool to ensure the right people are made available when they are needed. It also helps to let all involved have clear expectations about the length of their commitment to the project. Developing the staffing plan requires: Reviewing project staffing requirements

 sets

Reviewing the WBS, network diagram, and activity duration estimates being

used to develop the project schedule Identifying the start and completion times for the different people or skill

Entering these preliminary assignments into the project scheduling tool, if

one is being used or map them out on a calendar Reviewing the preliminary assignments with the team, activity owners, and

other key stakeholders Obtaining commitments and make adjustments as required to develop a

realistic staffing management plan Creating Project Organization Chart Reporting relationships and areas of responsibility need to be communicated to key project stakeholders. An organization chart is a simple visual means to accomplish this task. Everyone needs to know who is responsible for what, who reports to whom, and the persons to contact for information on various subjects. Solid and dotted-line reporting relationships can both be included to show the organizational authority structure as well as the project organizational matrix relationships. Creating a project organization chart requires: project Listing the people by function or project phase in a hierarchical manner that Identifying the reporting relationships of everyone directly involved with the

clearly shows lines of authority Publishing the chart and send it to all key stakeholders

Documenting the Supporting Detail Information in addition to the key outputs of the organizational planning process must also be documented and will vary depending upon the project and organizational structure. Documenting the supporting detail normally requires: Documenting alternative organizational approaches to include a description

of each structure, the reason for its exclusion and the person responsible for making that decision; Creating job descriptions Identifying and describing training needs or activities that will be needed to

provide the necessary training must be incorporated into the project plan.

Lio 18: Aquisio de Equipe e

Desenvolvimento do Time
Objetivos da Lio: Uma tendncia contnua que vem influenciando a maneira como as empresas gerenciam os projetos que afetam a empresa inteira so as novas caractersticas do trabalhador profissional. Algumas caractersticas da equipe moderna que devem ser levadas em considerao que os trabalhadores agora so altamente treinados, com disponibilidade limitada e esto sempre em competio com outros empregadores. Eles tendem a estar envolvidos com vrios projetos ao mesmo tempo pela empresa (tanto nacional quanto internacional) e podem at trabalhar para outra organizao como firmas de consultoria. Um sistema efetivo de gerenciamento de projetos da empresa deve, portanto, fornecer um plano de como todos os recursos de tempo sero alocados, assim como uma viso de como o trabalho foi planejado e proposto. At o final dessa lio voc deve estar apto a: equipe Desenvolver um sistema de recompensas e reconhecimento Conduzir negociaes para formar sua equipe Articular uma estratgia de aquisio de uma equipe Elaborar exerccios de colaborao em grupo para criar um esprito de

Termos Chave Pool de Recursos Sala de Guerra do Projeto

Viso Geral Em um mundo em rpida mudana dos recursos humanos, o Gerente de Projetos enfrenta uma gama de desafios como downsizing, fuses, aquisies, globalizao e novas leis/regulamentaes. Alcanar as exigncias dos projetos em um tempo to turbulento requer muitos recursos altamente capacitados. Adquirir esses recursos e integr-los ao projeto a razo de existir da aquisio de equipe e desenvolvimento do time. Para adquirir corretamente uma equipe de projeto habilidosa e integrar eles com sucesso no projeto necessrio: Identificar a equipe interna desejada Negociar as alocaes de pessoal para a criao da equipe Identificar e recrutar novos membros Identificar e obter os recursos externos necessrios Publicar a lista da equipe

Conduzir as atividades iniciais para criao do esprito de equipe Estabilizar um sistema de reconhecimento e recompensa Colocar os membros da equipe para trabalhar no mesmo ambiente Organizar os treinamentos necessrios Servir de Coach os membros da equipe Identificar problemas e resolver conflitos

Identificando a Equipe Interna Desejada Saindo do pressuposto de que os recursos no foram pr-alocados no projeto, o processo de aquisio de recursos deve comear com uma avaliao dos candidatos internos (da empresa) disponveis para trabalhar no projeto. A chave para seleo da equipe identificar aquelas pessoas que as qualificaes e disponibilidades encaixam melhor com as necessidades do projeto. Pessoas responsveis pela aquisio da equipe devem determinar as prioridades da equipe e preparar meios alternativos de organizar as pessoas, j que as melhores pessoas nem sempre esto disponveis. O julgamento de cada candidato deve ser baseado nas suas capacidades de realizar suas respectivas tarefas no projeto. As qualidades que influenciam na performance de uma pessoa incluem capacidades como: Presena e performance Conhecimentos e habilidades especiais Histrico de trabalho Autorizao e custo de trabalhar fora do horrio (hora extra) Interesse no projeto

A equipe selecionada deve ter um bom mix de pessoas para garantir uma equipe que trabalhe bem junto. Gastar tempo para organizar um grupo de pessoas para trabalharem juntos sempre um desafio para o gerente de projetos, mas isso vai aumentar a chance de sucesso e prevenir problemas mais tarde no projeto. Para identificar a equipe interna desejada para o projeto necessrio: Comparar as necessidades de equipe com o Pool de Recursos Identificar aquelas pessoas mais prximas aos requisitos para as demandas

do projeto Identificar selees reserva para o caso de alguma pessoa se tornar

indisponvel Identificar falhas no plano de equipe onde os candidatos internos esto

indisponveis.

Negociando as Alocaes de Pessoal para a Criao da Equipe de responsabilidade do gerente de projetos, com o apoio do contratante do projeto (patrocinador), negociar com a gerencia funcional para obter a equipe necessria para completar o projeto com sucesso. Muitas vezes essa uma tarefa difcil quando os gerentes funcionais tm prioridades de alocao conflitantes com as necessidades do projeto. O problema acentuado pelo fato de que as melhores pessoas estarem sempre indisponvel e sendo muito procuradas. O Gerente de Projetos deve desenvolver um bom relacionamento com os gerentes funcionais e apresentar fortes argumentos sobre as razoes pelas quais certas pessoas so essenciais para o sucesso do projeto. Desentendimentos entre os gerentes de projetos e os gerentes funcionais podem ser resolvidos de 3 maneiras: identificar alternativas de selees, pedir ao contratante (patrocinador) para se envolver para re-priorizar as alocaes ou contratar a equipe necessria de outra empresa (terceirizar). Para negociar as alocaes de pessoal para a criao da equipe necessrio: Desenvolver bons relacionamentos com cada gerente funcional Ser assertivo sobre montar a equipe do projeto com as melhores pessoas Estar pronto para abrir a mo quando necessrio Identificar alternativas de selees internas de equipe Determinar a aplicabilidade e os custos envolvidos na contratao de

terceiros, caso necessrio Estabilizar uma situao de ganhos mtuos para que ambas as partes

atinjam seus objetivos Consultor o contratante do projeto (patrocinador) em casos onde no foi

possvel chegar a um acordo razovel Confirmar todas as negociaes as alocaes de pessoal para a Criao da

equipe por escrita Identificando e Recrutando Membros para Uma Nova Equipe Quando as pessoas necessrias no esto disponveis internamente, pode ser preciso recrutar pessoas qualificadas de fora da organizao. O primeiro passo obter a autorizao para recrutar e contratar. Isso normalmente alcanado quando se consegue aprovar as necessidades de pessoal pelo nvel gerencial adequado. Uma vez que a aprovao para continuar for obtida, um recrutador deve ser identificado e informado sobre as necessidades de equipe do projeto. O recrutador pode aconselhar o Gerente de Projeto sobre a disponibilidade geral das pessoas com as qualificados necessrias e sobre a estratgia de recrutamento mais eficiente. Os membros da equipe central do projeto e as outras partes interessadas devem entrevistar os candidatos qualificados para se ter uma avaliao mais rica,

envolvimento da equipe e uma participao nas decises de contratao. Para identificar e contratar membros para uma nova equipe de terceiros, a organizao deve: Obter autorizao para contratar externamente, incluindo os custos

relacionados com o recrutamento Trabalhar junto com o recrutador que possui a experincia em contratar as

pessoas com as qualificaes necessrias Desenvolver e implementar uma estratgia de recrutamento Permitir que membros da equipe chave e as partes interessadas entrevistem

os candidatos qualificados Selecionar os candidatos que vo trabalhar melhor com os outros membros

da equipe e que possuem as qualificaes mais adequadas Voc apenas to bom quanto as pessoas que voc contrata para fazer o trabalho. Contrate apenas os melhores. Referencia: Tylers Laws of Project Management, 1 Law of Hiring

Identificando e Obtendo os Recursos Externos Necessrios Projetos complexos normalmente precisam de habilidades especificas que possivelmente no pode ser encontrada dentro da prpria empresa. Nesses casos onde no se tem tempo para recrutar novos membros para a equipe ou quando a habilidade necessria apenas por um curto perodo de tempo, faz mais sentido obter ajuda de consultores qualificados e organizaes de servios. O uso seletivo de recursos externos pode ser de grande valor quando uma expertise especifica necessria e quando o tempo limitado. Deve-se ter cuidado para identificar os recursos com as habilidades necessrias que tenham boas referencias em seu ramo. Um conjunto claro de objetivos e entregveis deve ser acordado junto com um oramento e um prazo especifico para concluso. Para identificar e obter os recursos externos necessrios deve-se: Obter autorizao para contratar com agencias externas de emprego,

incluindo o oramento necessrio Identificar agencias de emprego qualificadas Solicitar propostas de agencias de emprego qualificadas Selecionar as agencias mais apropriadas Negociar um contrato com a agencia escolhida para marcar o tempo de

entrega dos servios ou entregveis em questo

Publicando a Lista da Equipe A lista da equipe do projeto deve conter todas as informaes importantes sobre os membros da equipe do projeto e outras partes interessadas incluindo nome, cargo, gerente funcional, local de trabalho, telefone de trabalho, fax e e-mail. A lista deve ser simples e de fcil edio que distribuda para todos os membros da equipe e as partes interessadas. Para publicar a lista da equipe deve-se: Obter as informaes necessrias de todos membros da equipe e das outras

partes interessadas Identificar quem precisa receber a lista da equipe Determinar a melhor maneira de fazer a distribuio (memorando ou

publicao, e-mail, link para o site do projeto)

Conduzindo as Atividades Iniciais para Criao do Esprito de Equipe Trabalho em equipe resultado de um grupo de indivduos aprendendo a trabalho juntos para um objetivo comum em uma atmosfera de confiana e respeito mtuos. Algumas vezes isso se desenvolve naturalmente ao longo do tempo enquanto as pessoas se conhecem melhor e algumas vezes ele criado sob a presso de se trabalhar em grupo para alcanar altos objetivos do projeto. No entanto, as demandas atuais dos projetos no podem esperar que isso ocorra espontaneamente, portanto os Gerentes de Projetos tomam algumas medidas para garantir que o trabalho em equipe vai ser desenvolvido rapidamente. Para criar o esprito de equipe deve-se: Organizar uma reunio de equipe fora do ambiente de trabalho para iniciar o

projeto Envolver todos os membros da equipe na formulao do cronograma e plano

do projeto Deixar os papeis, responsabilidades e expectativas bem claros Acordar em um conjunto de regras que vo servir de base para o

comportamento e interaes incluindo mtodos de moderar reunies, como solucionar os problemas, como tomar decises, como resolver conflitos e quando passar os problemas para os superiores Realizar atividades em grupo que permitam as pessoas se conhecerem

melhor e desenvolver respeito e confiana mutuas. Liderana a habilidade de ter as pessoas fazendo as coisas da maneira como voc quer e no como elas fazem normalmente. Liderana excepcional fazer as pessoas fazerem isso e ainda gostar. Referencia: Tylers Laws of Project Management, 4 Law of Leadership

Estabelecendo um Sistema de Recompensa e Reconhecimento Trabalhar em projeto muitas vezes sinnimo de trabalhar em cronogramas apertados e fazer sacrifcios pessoais. Embora seja importante que as pessoas tenham uma satisfao intrnseca pelo seu trabalho no projeto, tambm importante fornecer um reconhecimento externo e uma maneira formal de recompensa pelo trabalho bem feito. O reconhecimento pode ser feito de diversas maneiras, indo de conversas privadas para parabenizar as conquistas individuais at reconhecimento formal e prmios dos cargos gerenciais mais altos para um alto desempenho em equipe. Recompensas normalmente controladas de mais perto pelas polticas organizacionais e normalmente precisam de aprovao da gerencia. Recompensas podem ser tanto intrnsecas quanto extrnsecas. Recompensas intrnsecas podem ir desde levar a equipe para jantar at dar tempo de folga para as pessoas. Recompensas extrnsecas podem ir desde influenciar os aumentos normais por mrito at um programa de bnus por projeto ou outros programas baseados em desempenho. Para estabelecer um sistema de recompensas e reconhecimento deve-se: Identificar marcos chave no cronograma do projeto que podero servir como

bons momentos para reconhecimento e recompensas das conquistas individuais e da equipe Identificar maneiras informais de reconhecimento e recompensas

apropriadas que esto dentro da capacidade do gerente de projetos Identificar maneiras formais de reconhecimento e recompensas apropriadas,

mas que precisam de aprovao de cargos mais altos Buscar aprovao para o sistema de reconhecimento e recompensa do

projeto pelo contratante (patrocinador) e a gerencia funcional Administrar as recompensas e reconhecimentos de maneira igualitria e

imparcial baseado apenas nos resultados individuais e da equipe nos marcos importantes do projeto Elogie em Pblico. Critique em Particular. Referencia: Tylers Laws of Project Management. 2nd Law of Leadership

Colocando os Membros da Equipe para Trabalhar no Mesmo Ambiente Equipes de projetos so normalmente formadas por pessoas que realizam funes diferentes em lugares diferentes e apenas se renem como uma equipe para as reunies peridicas de acompanhamento. Caso contrario, as pessoas trocam cartas, e-mails e conversam primordialmente por telefone. Colocar os membros da equipe do projeto para trabalhar no mesmo ambiente provou-se uma tcnica eficiente para melhorar a comunicao e o trabalho em equipe. Quando as pessoas trabalham pertos uma das outras, elas vivenciam encontros informais mais freqentemente, se conhecem e confiam mais e so mais

capazes de assimilar informaes do projeto de modo formal ou informal. Membros que trabalham junto ficam isolados de responsabilidades funcionais que podem distra-los e podem se concentrar melhor no projeto. Se um projeto for particularmente importante para a organizao, ento adicionar um gasto maior para se adquirir um lugar de trabalho nico deve ser seriamente avaliado. Nos casos em que trabalhar em um mesmo ambiente no possvel, uma sala de guerra central do projeto deve ser arrumada, onde as informaes do projeto possam ser exibida nas paredes e os membros da equipe possam se reunir para discutir e solucionar problemas. Para aumentar a proximidade entre os membros deve-se: Estimar a proximidade fsica dos membros da equipe e determinar se coloc-

los no mesmo ambiente iria melhorar significativamente a comunicao da equipe Determinar se os benefcios potencias de colocar os membros no mesmo

ambiente iriam superar os custos Organizar uma sala de guerra do projeto para exibir e discutir as

informaes do projeto, quando trabalhar no mesmo ambiente no possvel Fornecer a equipe um sistema de e-mail fcil de usar para o envio de

comunicaes e a troca de documentos do projeto.

Organizar os Treinamentos Necessrios Gerentes de Projetos devem garantir que os membros da equipe tenham ambas as habilidades tcnicas e no-tcnicas necessrias para executar suas responsabilidades. Projetos como novos produtos e desenvolvimento de sistemas de informao iro normalmente envolver o uso de novas tecnologias que requerem novos conhecimentos e habilidades. No lado no-tcnico, um bom funcionamento da equipe precisa que os membros saibam tanto de metodologia de gerenciamento de projetos quanto de habilidades relacionadas a equipes. Embora o treinamento em gerenciamento de projetos possa ser feito individualmente ou em equipe, as habilidades de trabalho em equipe so melhor ensinados e praticados em grupo. Habilidades de trabalho em equipe incluem tpicos como: estgios da formao de equipe, gerenciamento de reunies, resoluo de problemas, tomada de decises, resoluo de conflitos, dinmicas de grupo e gerenciamento de diferenas interpessoais. Para garantir que o treinamento necessrio vai ser feito, deve-se: Identificar as habilidades necessrias para o bom desempenho da equipe Estimar as habilidades dos membros tanto pessoalmente quanto

coletivamente Agendar treinamentos tcnicos e no-tcnicos necessrios para a maioria

dos membros da equipe Encorajar os membros da equipe a dividirem seu conhecimento para ajudar

os outros a aprenderem

Servindo de Coach para os Membros da Equipe Muitos gerentes de projetos esto na difcil posio de ter a responsabilidade sobre o desempenho dos membros de sua equipe sem ter uma linha de autoridade direta sobre eles. Portanto, a maneira mais efetiva de melhorar o desempenho pela influencia e coaching. Coaching comea por observar onde as pessoas precisando de ajuda e deixar a porta aberta para que as pessoas se sintam livres para discutir seus problemas e preocupaes. Existem tambm os estilos gerenciais atravs dos quais o gerente de projeto interage com os membros da organizao. Existem 3 estilos bsicos de gerenciamento usados normalmente. Eles so o autocrtico, o deixa fazer deixa passar e o democrtico. O estilo autocrtico usa de fortes controles e um estilo ditatorial de gerenciamento. O estilo deixa fazer deixa passar estilo de gerenciamento no qual ningum est no comando com uma estratgia de no intervir. O estilo de gerenciamento Democrtico permite os membros da equipe participarem das decises. Ele cria comprometimento dos membros. praticamente impossvel usar apenas um estilo gerencial o tempo todo. O gerente de projetos experiente usa os diferentes estilos dependendo da situao e quando ela ocorreu. Junto com o estilo de gerenciamento, o gerente de projetos deve motivar sua equipe em direo ao objetivo do projeto. Diferentes gerentes de projetos j usaram, com sucesso, diferentes teorias motivacionais. Uma das teorias mais antigas baseada nos Fatores Higinicos de Fredrick Herzberg. Esses fatores so as polticas administrativas, as condies de trabalho, o salrio, a qualidade de vida pessoal, os relacionamentos, o status e a segurana. Esses fatores so necessrios, mas no so suficientes para motivar o trabalhador. Fatores Higinicos precrios podem destruir a motivao, mas melhor-los dentro de condies normais no vai melhorar a motivao. Motivao resulta da oportunidade de atingir e experimentar a auto-realizao. Os Agentes Motivacionais de Herzberg so reconhecimento, gostar do trabalho, responsabilidade e crescimento profissional. Outro conceito motivacional a Hierarquia das Necessidades de Maslow. Esse conceito trabalha com 5 nveis hierrquicos de necessidades. Comeando de baixo para cima eles so: Fisiolgico Ar, Comida, gua, Dormir Segurana Segurana Fsica, Estabilidade, Emprego Social Amizade, Famlia, Amor Estima Conquista, Confiana, Respeito, Ateno Auto-Realizao Crescimento, Aprendizado, Criatividade, Realizao

O conceito de satisfazer cada uma dessas etapas importante pois para Maslow a pessoa no pode subir para o prximo nvel at que suas necessidades mais bsicas sejam atendidas. Outro conceito utilizado a Teoria do X e Y de McGregor.

Para ele, os trabalhadores poderiam ser classificados em 2 tipos, o X e o Y. A Teoria X diz que o trabalhador mdio inerentemente preguioso e precisa de superviso. Mais ainda, esse trabalhador no gosta do trabalho e evita o trabalho sempre que possvel. Para conseguir o esforo adequado, o supervisor deve ameaar punies e supervisionar de perto. Nessas situaes o trabalhador mdio evita ter mais responsabilidades e busca ser direcionado. A Teoria Y, no entanto, diz que o trabalhador mdio quer ser ativo e acha o esforo mental e fsico no trabalho gratificante. Os melhores resultados vem da sua vontade de participar que normalmente gera um auto direcionado em direo aos objetivos sem coero ou controle. Nessa situao, o trabalhador mdio busca oportunidades de melhorias pessoais e confiana. De acordo com McGregor, a Teoria X depende de motivao externa como regras rgidas, incentivos de desempenho, recompensas e ameaas a segurana do emprego. J a Teoria Y depende de auto-motivao, participao do trabalhador nas decises, bom relacionamento de gerente-trabalhador e individualismo do trabalhador (dentro de certos limites). Para motivar a equipe do projeto deve-se: Entender que a equipe uma unidade organizacional completa Misso, objetivos, metas, estratgia e definio de papis na equipe,

somada os sistema de suporte da liderana e da organizao Gerente responsvel com as necessidades da equipe e que encoraja a

participao do funcionrio Gerentes que comunicam efetivamente e fornecer feedback Membros da equipe que se comunicam bem Confiana entre os membros da equipe e o gerente Designao individuais das responsabilidades sobre cada pacote de trabalho Cultura e estilo coletivos Planejamento de equipe para quem, o que, quando, onde e como

Algumas pessoas gerenciam pelo livro, mesmo que elas no queiram saber quem escreveu o livro, Ou at mesmo qual livro. Referencia: Tylers Laws of Project Management. 5nd Law of Leadership

Os Gerentes de projetos muitas vezes servem de um observador objetivo e fornecem viso, conselho e instruo onde necessrio. importante que o gerente seja visto pelos membros da equipe como uma pessoa fcil de se conversar e que quer ajud-las para alcanar sucesso individual e da equipe. Para melhorar o

desempenho da equipe deve-se: Observar o desempenho dos membros da equipe e identificar reas que

podem ser melhoradas Estar disponvel para os membros da equipe falarem dos seus problemas e

preocupaes Perguntar aos membros da equipe se eles precisam de ajuda Fazer coaching com os membros da equipe quando necessrio para melhorar

sua performance Voc gerencia objetos. Voc lidera pessoas. Tylers Law of Project Managemente. 3 Law os Leadership

Identificando Problemas e Resolvendo Conflitos Um dos papeis principais do gerente de projetos ajudar as pessoas a se concentrarem no seu trabalho e serem to produtivas quanto possvel. A produtividade dos membros da equipe pode ser negativamente afetada caso surjam conflitos. Conflitos podem tomar muitas formas, desde conflitos interpessoais entre membros da equipe at conflitos de alocaes de recursos entre os gerentes das organizaes funcionais. Gerenciamento de conflitos de responsabilidade do gerente de projetos. As vises que sero discutidas so a viso tradicional e a viso mais atual. A viso tradicional que os causadores de problemas causam os conflitos. J que isso ruim para o projeto ambos os causadores de problemas quanto os conflitos devem ser evitados. A viso mais atual que os conflitos so inevitveis em um projeto (especialmente em uma organizao matricial) e isso normalmente benfico. Conflito um resultado natural de mudanas que pode ser gerenciado. Fontes de conflitos no ambiente de projeto incluem as prioridades do projeto, procedimentos administrativos, opinies tcnicas e trade-offs de desempenho. Outras fontes de recursos podem ser a utilizao dos recursos, necessidades de investimento, conflitos de cronograma e personalidades. Existem 5 maneiras reconhecidas de se resolver um conflito no ambiente de trabalho. Primeiro, existe a retirada ou desistncia. Essa soluo apenas temporria. um mtodo passivo e que no resolve o problema que causou o conflito. Segundo, existe a suavizao. Isso envolve condescendncia ou acordos ressentidos. Esse mtodo evita o conflitos e no fornece uma soluo duradoura. Depois, existe o abrir mo. Abrir mo envolve uma negociao para alcanar um acordo aceitvel. Ele no tem uma soluo para os problemas e precisa de um escolha. O prximo metido Confrontar/Resolver Problema. Esse mtodo uma abordagem direta para atacar o problema e resolv-lo objetivamente. Confrontar/Resolver Problema envolver dialogo aberto para chegar-se a solues finais. Por ltimo, existe o Forar ou usar do poder para alcanar a resoluo do conflito. Esse mtodo envolve uma situao de perda e ganho. Qualquer um que j leu os Sete Hbitos das Pessoas Altamente Eficazes de Stephen Covey sabe que uma situao de perda e ganho

no a abordagem apropriada. Ele causa sentimentos ruins que acabam voltando como problemas mais tarde. Mais ainda, isso deteriora a capacidade do gerente de projetos de usar as fontes ou bases de poder. Normalmente, existem 5 fontes de poder dentro de uma organizao. Elas so: Formal, Recompensa, Penalidade, Experincia e Referencia. Formas legitimas de poder como formal, recompensa e penalidade so tipos de poder que o gerente de projetos tem pela sua posio na organizao. Esses tipos de poder tambm so chamados de poder da posio. Embora o gerente de projetos possa, e algumas vezes, deva exercer esse poder, ele muito limitado pela aceitao e normalmente no causa mudanas no comportamento. As Fontes de Poder Experincia e Referencia que vem com a quantidade de conhecimento que uma pessoa possui e sua personalidade. Um gerente de projetos pode usar essas fontes de poder para influenciar as partes interessadas e at aqueles externos ao projeto. Para ajudar na resoluo de um conflito, a maioria dos gerentes de projetos tentam chegar a um consenso. Existem algumas regras aceitas para se chegar ao consenso. Essas regras incluem: Focar em derrotar o problema, no uns aos outros Evitar votao, trocas ou medias Buscar fatos para evitar dilemas Aceitar os conflitos como algo positivo e no permitir que ele estimule

ameaas ou aes defensivas Evitar comportamentos individualistas que excluem as necessidades e

posies dos outros A identificao dos conflitos depende do gerente de projetos e deve ser feito o quanto antes, assim o gerente dele resolv-los antes que eles tenham um impacto negativo no cronograma e objetivos do projeto. Para identificar e resolver conflitos deve-se: Antecipar potenciais conflitos e tomar aes preventivas sempre que

possvel Estar ciente dos conflitos assim que eles aparecerem e buscar entender suas

causas razes Encorajar os membros da equipe a resolverem os conflitos por conta prpria

ou com seus gerentes funcionais primeiro Buscar um soluo onde todos ganham para que ambos os lados possam

atingir seus objetivos Buscar ajuda do contratante (patrocinador) para resolver conflitos que esto

acima da alada do gerente de projetos Espere o melhor do seu pessoal. Eles nunca vo falhar em alcanar ou superar as suas expectativas sobre eles.

Lio 19: Planejamento das Comunicao e da Distribuio de Informaes

Objetivos da Lio: O PMBOK prescreve que o Gerenciamento das Comunicaes do Projeto fornece um relacionamento essencial entre as pessoas, idias e informaes necessrias para o sucesso do projeto. Planejamento das Comunicaes envolve a determinao das comunicaes e informaes necessrias para as partes interessadas dos projetos, em outras palavras, quem precisa qual informao, quando e em qual formato. A maior parte das comunicaes do projeto so concludas no comeo do projeto. No entanto, deve-se realizar revises regular para garantir que as necessidades das partes interessadas esto sendo atendidas. A estratgia de comunicaes est diretamente relacionada com a organizao estrutural do projeto e envolve a distribuio de informaes. Distribuio da Informao essencial para entregar as informaes a tempo. O gerente de projeto deve planejar quem ira receber as informaes e quando ela deve ser entregue. At o final dessa lio voc deve estar apto a: Exigncias de Comunicaes Tecnologias de Comunicaes Habilidades de Comunicaes Sistema de Recuperao das Informaes Sistema de Distribuio das Informaoes

Termos Chave Cdigo Mensagem Canal Receptor Ciclo de feedback

Viso Geral

Muitos gerentes de projetos se sentem confusos com o labirinto de gastar mais dinheiro em mais tecnologia para alcanar as partes interessadas de maneira menos eficiente. Existem vrias alternativas poderosas e lucrativas para os mtodos tradicionais informaes. de planejamento tecnologias das como comunicaes voice mail, e distribuio de Ferramentas e-mail, websites

inteligentes e bancos de dados no esto apenas possibilitando alcanar as partes interessadas de maneira individual e personalizada, elas esto redefinindo os princpios de gerenciamento das comunicaes. Para se conseguir ganhar vantagem das novas tecnologias de comunicaes as seguintes atividades so necessrias: Definir as exigncias de comunicao das partes interessadas chave Identificar a mdia apropriada para as comunicaes Desenvolver o Plano de Gerenciamento das Comunicaes Instituir um sistema de distribuio das informaes para as partes

interessadas Documentar as necessidades de comunicao do projeto Buscar feedback sobre a qualidade das comunicaes

Definindo as Exigncias de Comunicao das Partes Interessadas Chave Um pr-requisito bsico para o sucesso do projeto uma comunicao efetiva entre os membros da equipe e entre a equipe do projeto e as outras partes interessadas. As exigncias de comunicaes normalmente focada em atender as necessidades de informao de 4 grupos primrios. Os membros da equipe do projeto dever ser mantidos informados do status do projeto, das mudanas no ambiente ou no projeto e sobre suas responsabilidades. Os clientes esto largamente interessados no progresso do projeto e devem manter suas responsabilidades nos processos relacionados com as definies de requisitos, gerenciamento da mudana e na tomada de decises. A gerencia snior est preocupada com o desempenho do projeto e deve ser periodicamente informada sobre o progresso do projeto, problemas e riscos. As organizaes funcionais devem estar cientes de quando eles precisam dar suporte ao projeto e quais atividades so necessrias de seu pessoal. Um modelo de comunicao pode ser usado para entender e alcanar as necessidades de informaes desses 4 grupos primrios. Existe o modelo de 5 partes da comunicao. Existe o Emissor, ou seja, a pessoa que inicia a comunicao. Isso inclui a organizao, os supervisores, os companheiros de trabalho, o cliente e os associados. Depois existe o Cdigo no qual as idias do Emissor so traduzidas em um conjunto de smbolos que fornecem um estrutura na qual as ideais, propostas, intenes podem ser expressas como uma mensagem coerente. A Mensagem o produto fsico da mensagem codificada do Emissor. Ela uma idia apresentada do Emissor para o Receptor em um cdigo conhecido por ambos. O Canal o meio usado para levar a mensagem do Emissor para o Receptor. E por ltimo, o Receptor quem recebe a mensagem. Nenhuma comunicao acontece at o receptor aceitar e compreender a mensagem enviada

pelo Emissor. A mensagem no est completa at que o receptor avise para o Emissor que a mensagem foi recebida e compreendida. Para qualquer um que use File Transfer Protocol (FTP) na internet, isso facilmente compreensvel. O gerente de projetos um expedidor de comunicaes que mantm contato com todas as facetas do projeto e seus participantes. O Receptor normalmente filtra a mensagem com a sua prpria interpretao. O Emissor deve procurar feedback para garantir que a mensagem foi recebida e entendida da maneira correta. Uma m recepo est na maioria das vezes associadas a esse processo de filtrar. Filtrar um fenmeno que ocorre quando uma grande parte da mensagem perdida na transferncia entre os subordinados at os supervisores. reas que normalmente causam essa filtrao so: um Reputao/Autoridade Status na Organizao Backgroup ambiental onde as pessoas vieram de contextos totalmente Linguagem que naturalmente ambgua e no a melhor opo para

descrever requisitos dos entregveis do projeto Cultura ou costumes dos indivduos do projeto ou maneiras de fazer

negcios Semntica ou mal entendidos causados pela subjetividade das

interpretaes Diferena entre a base de conhecimento/inteligncia daqueles que esto

recebendo a mensagem em relao ao Emissor Contedo da Mensagem onde a mensagem pode ter sido baseada em

alguma premissa que no foi comunicada para o receptor tica onde a mensagem entregue e percebida baseada na tica de cada

diferentes psicolgicos, sociais e emocionais Avaliao da Situao quando a pessoa j tem uma Idea predeterminada

antes de receber a mensagem Avaliao Histrica onde ns sempre fizemos assim desempenha um

grande papel na interpretao da mensagem Uma comunicao completa consiste de 2 Emissores e 2 Receptor, onde apenas 1 Emissor e 1 Receptor podem agir por vez. Referencia: Tylers Law of Project Management. 1 Law of Communications.

Fora os filtros, existem tambm as barreiras que so um obstculo para uma boa comunicao no projeto. Algumas barreiras achadas nos projetos incluem:

Jogos de poder Reteno de Informaes Gerenciando por memorando No ter canais claros de comunicao Distancia fsica entre o emissor e o receptor Comportamento emocional defensivo dos participantes Premissas no fundamentadas Interesses particulares Barulho ou fatores ambientais Hostilidades

Para superar as barreiras e os filtros o gerente de projetos deve adotar tcnicas de escutar. Uma tcnica usar o Modelo de Escutar que inclui os modelos Cognitivos, Afetivos e Psicolgicos. O modelo Cognitivo passa por escutar, raciocinar e intuio. O modelo Afetivo passa por emoes ou sentimentos e no pela razo. E o modelo Psicolgico possui varias maneiras e motivos de controlar o ouvinte. Para desenvolver habilidades de escutar o gerente de projetos deve parar de falar, deixar o emissor da mensagem relaxado e ser atencioso mostrando o desejo de escutar. Voc deve eliminar as distraes, mostrar empatia com o Emissor, ter pacincia e manter qualquer o auto-controle. Se voc for criticar, critique apenas voc mesmo e no os outros e pergunte para entender algum ponto confuso. Para definir as exigncias de comunicaes de um projeto deve-se: Identificar os vrios grupos de partes interessadas do projeto Discutir as necessidades de comunicaes relativas ao projeto com os

representantes de cada grupo de parte interessada Determinar quais informaes cada grupo precisa, sua periodicidade e qual

ser o melhor formato Documentar as informaes das necessidades das partes interessadas em

uma matriz simples e desenvolver exemplos de diferentes tipos de comunicaes Criar exemplos de comunicaes e pegar um feedback dos representantes

das partes interessadas Validar o plano de gerenciamento das comunicaes atravs da distribuio

da matriz para os representantes dos grupos de partes interessadas

Identificando a Mdia Apropriada para a Comunicao A equipe do projeto deve determinar o melhor mtodo para distribuir as informaes do projeto necessrias para satisfazer os diferentes grupos de partes interessadas. Existe uma grande variedade de alternativas para a comunicao hoje

em dia, indo do tradicional relatrio fsico at e-mail, vdeo conferencias e intranets. A seleo da tecnologia e mdia mais apropriada depende de vrios fatores: preferncias pessoais, proximidade fsica dos indivduos, tamanho e complexidade do projeto, cultura organizacional, disponibilidade da tecnologia e os recursos disponveis para formar a comunicao. O gerente de projeto tambm deve entender os 4 tipos de comunicaes que ocorrem dentro do projeto. Primeiro, existem os componentes estruturais: Audincia ou receptores da mensagem Processo ou mecanismo de entrega da mensagem Habilidades ou contexto no qual a mensagem dada, ambiental ou um

mtodo de comunicao (escrito, oral, etc) Aplicaes ou quando e onde para facilitar a entrega da mensagem

Depois existem os tipos Escritos de comunicaes. Isso envolve veculos de comunicao formais e informais. Veculos Formais de comunicao incluem a declarao da misso da empresa, o termo de abertura do projeto, relatrios anuais, relatrios do projeto e anotaes das reunies. Veculos Informais de comunicao incluem memorando, anotaes pessoais, post-its. Alem dos tipos escritos de comunicao, existem as formas Orais. Esse tipo tambm envolve veculos formais e informais. Os veculos de comunicao oral formais so reunies de todos os tipos, revises do projeto, avaliao de desempenho e feedback do cliente. Os veculos de comunicao oral informais envolvem contato pessoal, reunies informais, discusses no corredor e encontros sociais. O ultimo tipo de comunicao realizada em um projeto a No-Verbal. Esse tipo tambm envolve os tipos formais e informais. Comunicaes no-verbais formais incluem apresentaes, grficos e vdeos. Comunicaes no-verbais informais envolve linguagem comportamental, expresses faciais e contato visual. Mecanismos de comunicaes no projeto normalmente incluem: Membros da equipe do projeto usando relatrios de status do projeto

regularmente, reunies peridicas da equipe e encontros individuais para manter a comunicao durante o projeto Interaes com os clientes que normalmente ocorrem atravs de reunies

com o gerente de projetos, relatrios e documentao A equipe do projeto usando normalmente os relatrios de progresso do

projeto e briefings da gerencia como mtodo para comunicar os cargos mais altos de gerencia. Para identificar as mdias mais apropriadas deve-se: Identificar quais abordagens de comunicao foram bem sucedidas em

projetos parecidos Descobrir as preferncias das partes interessadas

Garantir que todas as partes interessadas tm acesso a mdia ou tecnologia

escolhida, como e-mail, relatrios online, etc. Conduzir uma demonstrao inicial da mdia ou tecnologia escolhida Fornecer treinamento para as mdias ou tecnologias escolhidas quando

necessrio

Desenvolvimento o Plano de Gerenciamento das Comunicaes O plano de gerenciamento das comunicaes, que subsidirio ao plano geral do projeto, defini as informaes e comunicaes necessrias do projeto e descreve os mtodos planejados para essa exigncia. Isso normalmente consiste de relatrios, reunies e acompanhamentos que foram planejados para manter a comunicao com cada uma das vrias partes interessadas. O plano deve especificar o formato e o contedo de cada informao que ser distribuda e indicar como cada uma delas deve ser feita. Ele tambm deve explicar como sero feitas as atualizaes no plano e que ser responsvel por identificar e fazer estes ajustes. Para desenvolver o plano de gerenciamento das comunicaes preciso documentar as necessidades de comunicaes das vrias partes interessadas e a mdia ou tecnologia de distribuio que ser usada. Tambm deve-se enviar o plano para as partes interessadas com o intuito de receber feedback e sugestes. Humanos, ao contrario das maquinas, no foram desenvolvidos para receber informaes de maneira automtica e repetitiva. Referencia: Tylers Law of Project Management. Corollary 3 to 1 Law of Communications.

Instituindo um Sistema de Distribuio de Informaes para as Partes Interessadas Como o ponto focal das comunicaes do projeto, o gerente de projetos responsvel por assegurar que o plano de gerenciamento das comunicaes devidamente implementado e que todas as partes interessadas do projeto recebam a informao que eles precisam dentro do prazo. Os membros da equipe do projeto so responsveis pela boa comunicao entre si de acordo com as necessidades do projeto e devem encaminhar todas as informaes relevantes do projeto para o gerente de projetos para uma distribuio mais ampla. Reunies da equipe, e-mail, bancos de dados, sistemas de gerenciamento de documentos, software de gerenciamento de projetos e a intranet da empresa podem ser usados para facilitar e agilizar a distribuio e registro das informaes do projeto. Para distribuir as informaes deve-se: Revisar e implementar o plano de gerenciamento das comunicaes Conduzir reunies do projeto, quando necessrio, para manter as pessoas

informadas Comunicar todas as informaes relevantes do projeto informalmente e

formalmente quando necessrio Identificar e comunicar barreiras a execuo do projeto Tentar responder a pedidos especiais de informaes pelas partes

interessadas chave A melhor deciso, utilizando a melhor informao, quando atrasada, por definio uma deciso errada. Tylers Laws of Project Management. 2 Law of Decision Making.

Documentando as Necessidades de Comunicao do Projeto A comunicao mais efetiva dos projeto normalmente a informal e oral. Os membros da equipe precisam trocar informaes continuamente para que todos mantenham-se informados sobre os vrios aspectos do projeto. Essas comunicaes devem ocorrem espontaneamente e no devem esperar por reunies formais da equipe ou relatrios de progresso. No entanto, muita coisa ocorre e muitos mal entendidos acontecem em projeto complexos para poder se apoiar somente nas comunicaes orais e na memria das pessoas. Qualquer informao que possa impactar o projeto, que precise ser largamente difundida ou seja usada como entrada para a tomada de decises no projeto tambm devem ser documentadas. A forma de documentao pode variar desde um e-mail informal at um memorando ou um relatrio do projeto. Para manter os registros de todas as comunicaes deve-se: Estar ciente de que qualquer informao do projeto comunicada

informalmente deve ser documentada desde que ela impacte o projeto, seja necessria para muitas pessoas ou sirva de entrada na tomada de deciso Buscando Feedback sobre a Qualidade das Comunicaes Foi feita uma tentativa de antecipar as necessidades de comunicaes das partes interessadas chave durante o desenvolvimento do plano de gerenciamento das comunicaes. Depois que o projeto foi iniciado e a equipe teve a experincia de distribuir as informaes do projeto, as partes interessadas devem ser procuradas para fornecer feedback sobre a adequao da informao que eles receberam. Um esforo deve ser feito para determinar se o tipo, formato e freqncia das Documentar as informaes de modo apropriado a sua importante e a

necessidades distribuio Encaminhar uma copia das informaes documentadas para o gerente de

projetos arquivar e exibir

informaes suficiente para atender as necessidades das partes interessadas. Em alguns casos, as partes interessadas iro indicar que eles precisam receber as informaes de modo mais detalhado e em uma freqncia maior. Em outros casos, os gerente sde projetos iro descobrir que algumas partes interessadas precisam de apenas informaes resumidas ou estarem apenas cientes se algum problema surgir. Para solicitar feedback sobre a adequao das comunicaes deve-se: Revisar o plano de gerenciamento das comunicaes Solicitar feedback das partes interessadas, oralmente ou por escrita, sobre

se as informaes esto adequadas aos seus propsitos Discutir o feedback com a equipe do projeto Atualizar o plano de gerenciamento das comunicaes

Comunicao, para ser efetiva, deve permitir um fluxo de duplo sentido. Comunicao de apenas um sentido definida como desastre.

Lio 20: Boletim de Performance e Fechamento Administrativo

Objetivos da lio:

Todo Gerente de Projeto experiente pode dizer que quanto maior o projeto, maior o seu risco. O potencial risco para o custo, cronograma, qualidade e outros fatores normalmente aumentam com o tamanho do projeto. Gerentes com equipes que envolvem centenas de pessoas passam grande parte do seu tempo planejando e agindo em cima de todo tipo de detalhes tericos, trabalhistas e logsticos. Quanto maior o projeto, mais recomendado que o Gerente foque em customizar seus boletins de comunicao de forma a satisfazer as necessidades da sua equipe, especialmente quando enfrentam problemas de implementao. lio voc deve poder: Conduzir uma avaliao de performance; Analisar a varincia do projeto; Analisar a tendncia do projeto; Analisar o valor adquirido do projeto; Ao final dessa

Elaborar boletins de performance.

Termos Importantes

Modelo de maturidade de capacidades; Anlise da varincia; Anlise da tendncia; Anlise do valor adquirido; Valor orado do trabalho agendado; Oramento do trabalho realizado; Real custo do trabalho realizado; Desvio de cronograma; Desvio de custo; ndice de desempenho de custo; Porcentagem de desvio do cronograma; Porcentagem de desvio do custo; Oramento ao completar; Estimativa aps completo.

O Guide to the PMBOK descreve boletim de progresso como o levantamento e disseminao de informaes do progresso do projeto. Isso inclui boletins para stakeholders com a avaliao dos recursos em relao aos objetivos do projeto. O trmino de um projeto consiste de verificar e documentar os resultados do projeto para formalizar a validao do patrocinador e cliente do projeto. Isso inclui a documentao do projeto para demonstrar que foram atendidas todas as especificaes e determinar o sucesso e eficcia do projeto. Tambm devem ser documentadas as lies aprendidas para consultas futuras. Cada fase de um projeto deve ter um fechamento administrativo para que nenhuma informao seja perdida. Um eficaz boletim de performance e fechamento administrativo requer: Levantar informaes sobre o andamento do projeto; Identificar varincias do plano inicial e as aes necessrias para corrigi-lo; Resumir a performance do projeto; Preencher e arquivar a documentao do projeto; Conduzir e documentar a avaliao do projeto ps-implementao;

Documentar a validao final do produto.

Levantar informaes sobre o andamento do projeto. O Gerente de Projetos age como um ponto onde todo o sistema de comunicao e boletim de performance dos projetos deve focar. Um modelo de boletim de performance deve ser especificado para todos os colaboradores do projeto e devem avaliar os diferentes elementos do planejamento do projeto incluindo escopo, cronograma, custo, qualidade e riscos. Alm disso, o boletim deve incluir uma Por exemplo, os Gerentes de Projeto seo para mudanas e aes recomendadas. A freqncia dessas avaliaes deve variar de acordo com a fase do projeto. normalmente aumentam a freqncia das avaliaes na medida em que a data de trmino do projeto se aproxima. O Gerente de Projeto deve saber balancear uma freqncia muito alta e detalhamento nas avaliaes (burocratizao) com a falta de dados que acarreta no mau entendimento e acompanhamento do projeto. Na maioria das vezes, os boletins de desempenho so distribudos via email. Alm disso, o software de gerenciamento de projeto tambm permite atualizaes do cronograma do projeto e o acesso a ele permitido por toda a rede da organizao. O boletim de progresso mais eficaz realizado atravs de reunies com a equipe para discutir assuntos importantes referentes ao projeto. Para obter a atualizao da performance do projeto necessrio: Rever o plano de gerenciamento de comunicao para identificar a

freqncia e formato necessrio; Comunicar a equipe para garantir que o boletim ser realizado em dia; Agendar reunies peridicas com a equipe para os membros discutirem

sobre a performance, preocupaes e problemas enfrentados durante o projeto; Dar feedback equipe no que diz respeito ao interesse demonstrado; Adequar a freqncia, formato e detalhamento dos boletins fase do

projeto. A anlise do valor adquirido (EVA) a ferramenta de medio do progresso do projeto mais utilizada hoje. A anlise do valor adquirido a medida objetiva de quanto trabalho j foi realizado em um projeto. com o que havia sido planejado. Utilizando o processo de valor adquirido, a gerncia pode imediatamente comparar quanto trabalho foi realizado O clculo do valor adquirido requere que o gerente do projeto planeje, orce e planeje o trabalho autorizado para a realizao do escopo em um plano de fase baseado em tempo. O plano de fase baseado em tempo o valor adquirido planejado do projeto, que tem como fim agir como uma linha de base para as medidas de performance. O valor adquirido compara justamente esse plano com o realizado. A varincia do plano pode ser identificada como uma variao no cronograma ou custo do projeto. O uso da anlise do valor adquirido envolve: Valor orado do trabalho agendado (BCWS) ou oramento planejado, Custo real de realizao do projeto (ACWP) e Valor real do trabalho agendado (BCWP), ou

valor adquirido.

A varincia de custo (CV) mostra a diferena entre o valor do

projeto hoje e o que foi gasto para chegar onde ele est e a varincia de cronograma (SV) mostra a diferena entre onde o projeto deveria estar em relao a onde ele est. A frmula para varincia de custo : CV=BCWP-ACWP e para a varincia de cronograma : SV=BCWP-BCWS. O Gerente do projeto pode utilizar a varincia de custo (CV) e varincia de cronograma (SV) separadamente ou em conjunto para realizar uma anlise de varincia total do projeto. Caso o CV seja positivo e o SV negativo, as atividades no comearam quando deveriam ou no foram aplicados os recursos necessrios. Se o CV e SV forem negativos, os custos do projeto esto muito altos e ele est atrasado. Se o CV negativo e o SV positivo, o projeto est abaixo do orado e frente do cronograma. Alm do uso do CV e SV, a anlise do ndice de desempenho de custos (CPI) tambm pode ser realizada para medir o nvel de performance do projeto. A frmula para o CPI : BCWP/ACWP. Se o CPI maior do que 1, a performance do projeto excepcional. Se o CPI menor do que 1, a performance do projeto est abaixo do esperado. Para definir a meta do projeto, o Gerente deve identificar o oramento ao completar (BAC). O BAC a soma de todos os oramentos (BCWS) alocados para o projeto. Esse o esforo total planejado para o projeto. Tambm utilizada a anlise da estimativa para concluso (EAC). A frmula para EAC : EAC=[(ACWP/BCWP)*BAC] expresso em dlar ou horas. A EAC permite uma

anlise realista do trabalho realizado e o Gerente do Projeto pode realizar uma anlise da tendncia do projeto. a soma de todos os custos diretos e indiretos realizados mais a estimativa do que ainda resta. A Varincia para concluso (VAC) a melhor estimativa do custo total para concluso do projeto expressa em porcentagem acima/abaixo da quantia orada. Finalmente, se o Gerente do projeto deseja uma anlise precisa da varincia de custo e cronograma do projeto, uma anlise de porcentagem da CV e SV podem ser expressas da seguinte forma: SV%= (SV/BCWS) X 100 or [(BCWP - BCWS)/BCWS] X 100 CV% = (CV/BCWP) X 100 or [(BCWP - ACWP)/BCWP] X 100

Identificar Varincias do Planejamento Inicial e Aes Corretivas A equipe deve fornecer ao Gerente um follow-up de seu progresso em relao ao planejamento do projeto. Varincias, tanto positivas quanto negativas, devem ser identificadas, assim como qualquer outra ao recomendada. As varincias em relao ao plano incluem escopo, cronograma, custo, qualidade e condies de risco. As reunies da equipe do projeto devem focar nesses aspectos para que sejam eficientes e produtivas, e aes corretivas devem ser identificadas e realizadas para corrigir o planejamento do projeto. Para identificar as varincias do plano e aes corretivas, necessrio: Comparar o boletim de performance com o planejamento do projeto; Identificar as varincias do plano, tanto positivas quanto negativas; Identificar as causas das varincias;

Definir aes corretivas e eventuais mudanas no planejamento do projeto.

Resumir a Performance do Projeto Apesar das reunies com todos os membros da equipe fazerem com que a performance do projeto seja clara para todos, o gerente do projeto deve ter um entendimento maior do andamento do mesmo. responsabilidade do Gerente do projeto coletar, sintetizar e resumir as informaes para toda a equipe, patrocinador do projeto e quaisquer outros stakeholders. Os resumos devem ser breves, porm compreensivos e completos. Para resumir a performance do projeto necessrio: Levantar as informaes chave dos boletins de performance individuais; Enfatizar o que evoluiu desde o ltimo perodo de avaliao; Identificar os fatores crticos e reas de risco; Definir aes corretivas e eventuais mudanas para o planejamento do

projeto. Completar e arquivar a Documentao do Projeto Todo projeto produz uma variedade de documentos durante o seu ciclo de vida. Esses documentos dizem respeito tanto ao produto quanto a realizao do projeto em si. Todos eles devem ser acumulados, verificados e arquivados para uso no futuro. Para completar e arquivar esses documentos, necessrio: Levantar todas as medidas do projeto e document-las para registrar e

analisar os processos, performance e atualizaes do projeto; Levantar toda a documentao relativa ao produto do projeto, incluindo sua

descrio, especificao, desenhos, testes, etc; Revisar toda a documentao para verificar sua preciso e totalidade; Revisar toda a documentao para certificar que refletem as ltimas

especificaes; Arquivar os registros do projeto para uso futuro.

Conduzir e Documentar a avaliao ps-implementao Organizaes eficazes fazem o possvel para aprenderem com os erros e acertos do passado. Todo projeto passar por sucessos e dificuldades e importante que esses sejam identificados, analisados e comunicados. Alm disso, aes corretivas devem ser planejadas de forma a prevenir problemas recorrentes nos projetos e fases futuras. Esse processo , normalmente, chamado de lies aprendidas e um aspecto fundamental do processo de modelo de maturidade das capacidades. Para conduzir e documentar a avaliao de uma fase ou projeto necessrio: Revisar e analisar os registros do projeto;

Preparar para a validao ps-implementao ao identificar o que deu certo

e errado no projeto; Organizar uma reunio com a equipe e colaboradores chaves do projeto; Concordar nos sucessos do projeto que poderiam ser replicados em outras

fases ou projetos; Concordar nos problemas do projeto e o que pode ser feito para evit-los

numa futura fase ou projeto; Delegar a implementao das aes corretivas; Fazer uma reunio com o patrocinador caso ele no esteja presente na

anterior; Elaborar um relatrio de ps-implementao e distribu-lo para as pessoas

que podem aprender com ele; Incluir o relatrio como registro do projeto.

Documentar a Aceitao Final do Produto A validao do produto, da fase ou projeto por parte do consumidor, cliente ou patrocinador deve ser documentada e compor os registros do projeto. Isso de extrema importncia para evitar problemas legais no futuro. validao da fase, produto ou projeto, necessrio: Resolver todas as pendncias que possam ter feito com que a aceitao final Para documentar a

do projeto fosse condicional; Preparar a carta de validao e requerer a aprovao do consumidor, cliente

ou patrocinador; Distribuir cpias da validao para todas as partes interessadas no projeto.

Lio 21: Identificao e Quantificao de Riscos

Objetivos: Existe uma variedade de mtodos para a caracterizao de incertezas e variveis. Esses mtodos cobrem um campo de complexidade muito grande que abrangem desde comparaes simples de pontos discretos at tcnicas probabilsticas como a Analise de Monte Carlo. De acordo com o Guide to the PMBOK, a identificao de riscos consiste em determinar quais riscos so mais

provveis de afetar o projeto e documentar as caractersticas de cada um deles. Isso no algo que se faa apenas uma vez, deve ser realizado regularmente durante o projeto. Adicionalmente, identificao de riscos envolve a avaliao de riscos e interaes de riscos, a fim de avaliar o alcance de possveis resultados nos projetos. Esse processo se preocupa em determinar quais eventos de riscos necessitam de uma resposta. At o fim dessa lio voc devera entender como usar:

Checklist; Flowcharting; Tcnicas de entrevistas; Valor monetrio esperado; Somas de Satisfao; Simulaes; rvores de Decises.

Termos Importantes:

Flowcharting; Valor Monetrio Esperado; Retorno de Investimento; Somas Estatsticas; rvores de Decises; Tcnica Delphi; Monte Carlo ou Modelagem de Risco.

Panorama:

A definio de riscos o processo que identifica, analisa e reponde as incertezas. Isso inclui maximizar os resultados de eventos positivos e minimizar as consequncias de eventos adversos. A gerncia tem obrigao de tomar decises formais e informais que iro levar ao sucesso da organizao. Em um mundo perfeito, decises seriam feitas com total certeza. No mundo real essas situaes raramente existem. Isso leva incerteza como resultado da deciso. No entanto,

sem informao ou conhecimento, nada se sabe sobre o possvel resultado e a total incerteza passa a existir.

Aspectos de Gerenciamento de Riscos so identificaes, quantificaes, desenvolvimento de respostas (tambm conhecido como atenuao) e controle de respostas. Os primeiros dois aspectos sero discutidos nessa lio e os outros dois sero discutidos na prxima lio. Identificao e quantificao de riscos envolvem:

Avaliao de desempenho de projetos antigos; Revisar o plano de projetos para a preveno de riscos potenciais; Identificar eventos de riscos potenciais; Monitorao do desempenho do projeto para identificao de

sintomas de riscos; Fornecimento de entradas para outros processos; Estimao da probabilidade dos eventos de risco; Estimao do impacto do evento de risco; Criao de uma matriz de taxao de riscos.

Avaliando o Desempenho de Projetos Antigos

Identificao de riscos o processo de tentar antecipar as consequncias futuras de suposies e aes. Esperar o inesperado uma habilidade que s pode ser desenvolvida com experincia. Felizmente, Gerentes e membros da equipe no precisam depender somente de sua experincia prpria ou da experincia coletiva do grupo. Eles podem consultar projetos antigos para aprender com a experincia de outros. O jeito mais eficiente de avaliar o desempenho de projetos antigos para ganhar entendimento em um projeto atual analisar as causas razes dos problemas que impactaram negativamente o projeto antigo. Problemas chaves so definidos como aqueles cuja ao ou situao resultaram que o projeto no evolusse como esperado. Alguns problemas tpicos so:

esquecida; entende bem;

Perceber

que

uma

atividade

significativa

foi

subestimada

ou

Um recurso chave no estar disponvel quando necessrio; Dificuldade em implementar um requerimento terico que no se

O cliente mudar suas necessidades depois de um trabalho extenso de

design ter sido feito; A equipe assumiu situaes perfeitas de trabalho e no se

preocupou em preparar aes corretivas para eventuais riscos.

Avaliar o desempenho de projetos antigos requer:

Identificar projetos antigos similares ao projeto em andamento; Entrevistar o Gerente de projeto, sua equipe e colaboradores; Quantificar a informao adquirida; Examinar os arquivos do projeto e as lies aprendidas; Determinar quais lies podem ser aprendidas e quais riscos devem

ser considerados.

Revisando o Plano de Projetos para a Preveno de Riscos Potenciais

Antes de lidar com riscos, voc deve conhec-los e a identificao de riscos exatamente o processo usado para obter esse conhecimento.

Esse processo implementado: no desenvolvimento de vrios elementos do plano de projeto, depois que o plano preliminar estiver completo e durante a execuo e controle do projeto. Portanto, pode se concluir que a identificao de riscos deve ser realizada tanto na fase de planejamento inicial como na fase de execuo e controle do projeto. Por mais que a identificao de riscos seja uma responsabilidade recorrente do Gerente de Projeto e da equipe, ela normalmente realizada mais rigorosamente nas etapas mais tardias do planejamento de projeto. Nesse momento, cada elemento do plano de projetos avaliado para identificar riscos potenciais. A viabilidade de completar um projeto com certo nmero fixo de restries s pode ser avaliada efetivamente depois que a maioria do plano foi elaborado.

Isso devido ao fato do risco ser resultado de trocas que devem ser feitas entre o escopo do projeto, qualidade, tempo e custo. Quase sempre o escopo e qualidade do projeto podem ser alcanados com um mnimo de riscos envolvidos, dados tempo e recursos ilimitados. Da mesma forma, possvel obter uma grande variao de cronogramas se o escopo do projeto puder ser reduzido para o tempo disponvel ou recursos ilimitados. Esse o momento onde a equipe deve negociar

essas trocas entre essas quatro variveis que o risco apresenta. Revisar o plano de projeto para identificar riscos potenciais requer:

Preparar

uma

analise

de

requerimento

para

identificar

riscos

intrnsecos do projeto e filtrar requerimentos; Determinar se os objetivos do projeto esto claros (se o escopo no

estiver bem definido, no ser possvel identificar as possveis reas de riscos); Determinar at onde os requerimentos do projeto se encaixam com

as competncias da organizao; Determinar at onde o sucesso do projeto depende de tecnologias

novas ou no comprovadas; Revisar o WBS para verificar quais atividades facilmente esquecidas

esto presentes; Revisar a preciso da durao de cada atividade que se encontra no

caminho crtico e das atividades com maior durao; Revisar suposies sobre o tempo de trabalho de cada membro para

que no haja conflito com suas responsabilidades; Revisar suposies feitas sobre questes tericas chaves; Revisar suposies feitas na etapa de planejamento de recursos

como, por exemplo, ter certa habilidade disponvel quando necessrio; Criar uma lista geral de reas de riscos potenciais.

Identificando Eventos de Riscos Potenciais

Eventos de riscos so ocorrncias discretas que podem ter efeito negativo no projeto. Eles podem variar de perda de membros da equipe ou a falha de um terceirizado, rejeio do produto final pelo cliente. Existem dois tipos bsicos de risco. O primeiro um risco empresarial, e ele lida com chance de lucro ou perda com empreendimento. O segundo o risco assegurvel. Ele envolve somente a chance de perda como danos de construo. Existem vrios tipos de riscos assegurveis:

equipamento;

Dano propriedade direta; Perda conseqente indireta como remoo de entulho e troca de

Responsabilidade legal perante erros de design, ferimento corporal

pblico e falha no projeto;

Para identificar as incertezas no processo de identificao de riscos necessrio usar um meio de organizao como WBS - que desenvolve definies bsicas como o que so riscos altos, mdios e baixos e envolve tcnicas de conhecimento especfico como:

Tcnica Delphi; Lies Aprendidas; Brainstorming; Conferncias; Anlise de sensibilidade; Monte Carlo ou Modelagem de Risco; rvore de Anlise de Decises; Valor Esperado; Distribuio de Probabilidade; Por em Prtica Trabalho Existente; Cronogramas; Estimao de Custos; Documentos tcnicos; Sistema de Informaes Anlogas.

Depender de pessoas (incluindo patrocinadores, gerentes e membros da equipe) e outras organizaes, fora do controle da prpria organizao do projeto aumenta tremendamente os riscos do projeto e devem ser considerados eventos de risco. Muita dependncia em tecnologias novas ou no comprovadas e milestones tcnicos devem ser identificados como possveis eventos de risco. Outros riscos a serem considerados so: aes da natureza, mudanas legislativas, inovaes da concorrncia, instabilidade poltica e mudanas na economia. Identificar riscos potenciais requer:

Identificar dependncias em indivduos ou organizaes fora do

controle da prpria organizao; Identificar eventos de risco dentro do escopo do projeto;

 comprovadas; projeto;

Identificar quais milestones dependem de tecnologias novas ou no

Identificar aprovaes de milestones de clientes chaves; Identificar potenciais riscos de meio ambiente que podem impactar o

Criar uma lista de eventos de risco.

Monitorando o Desempenho do Projeto para Achar Sintomas de Risco

Como dito antes, a identificao de riscos um processo recorrente e responsabilidade do gerente de projetos e sua equipe. Muitos riscos no podem ser antecipados e s se revelam com o andamento do projeto. muito importante que o Gerente de Projetos e sua equipe tenham sensibilidade com os sintomas de potenciais riscos. Monitorar o desempenho do projeto para achar sintomas de risco requer:

Identificar aes e eventos durante a execuo do projeto que

invalidam as suposies feitas durante o processo de planejamento; Identificar sintomas de riscos antecipados; Listar esses sintomas de risco para a avaliao da equipe.

Fornecendo Entradas Para Outros Processos do Projeto

A identificao de riscos passa a ser til somente quando essa informao for passada para outros processos de gerenciamento do projeto para serem analisadas. Alguns dos processos que necessitam receber essas informaes so: Desenvolvimento de Precauo de Risos, Controle de Precauo de Riscos, Execuo do Plano do Projeto, Controle de Mudanas do Escopo, Controle do Cronograma e Controle de Custo. Fornecer informaes para outros processos requer:

Assimilar quais elementos do plano do projeto os riscos impactam; Determinar os impactos potenciais das reas e eventos de risco e

fazer mudanas nessas reas como necessrio; Ter certeza que todos riscos identificados sero devidamente

avaliados e que as decises necessrias sero tomadas.

Estimando a Probabilidade do Evento de Risco

Quantificao de risco descreve o efeito de um risco em termos concretos, que pode vir a impactar o projeto. A quantificao de riscos efetuada da melhor forma quando examinamos cada elemento do projeto individualmente. Certos eventos de riscos podem no ser analisados mais a fundo, dependendo da poltica da empresa, mesmo tendo um possvel impacto no projeto. pela quantificao de riscos que pode se analisar e comparar riscos para decidir quais deles tero um maior impacto. Por exemplo, um evento de risco fora do escopo pode seriamente impactar outras atividades da organizao. Nesse caso, a resposta a esses riscos pode ser incorporada no planejamento de negcios da organizao, ao invs de ser incorporada no nvel do projeto para evitar repeties. Elementos de informaes disponveis e a informao de vrios experts so reunidas para se estimar a probabilidade de ocorrncia para cada evento. Essa uma das tarefas mais subjetivas, mas existe um nmero de procedimentos que podem ajudar como: diagramas de influncia, anlise de contribuio de riscos, distribuio de probabilidade, rvores de probabilidade, modelagem de riscos e perfis de sensibilidade.

Onde a determinao de probabilidade elusiva, existem tcnicas mais elaboradas. No entanto, tome cuidado com o excesso de confiana na preciso dos resultados dessas tcnicas. Na melhor hiptese, elas so estimativas baseadas em boas experincias e opinies criativas.

Estimar a probabilidade de eventos de risco requer:

Examinar

elementos

individuais

da

quebra

do

trabalho

que

apresentem uma fonte de risco; Determinar o padro de preciso necessrio para estimar as

probabilidades; Escolher um mtodo para estimar; Estimar e arquivar as probabilidades de eventos de risco para o

projeto como um todo.

Estimando Valor/Impacto do Evento de Risco

O valor/impacto do evento de risco uma estimativa do ganho ou da perda com o acontecimento do risco. Esse valor ser aplicado a todos os elementos do projeto

como

oramento,

escopo,

qualidade,

cronograma.

Para

assimilar

as

conseqncias e a seriedade dos eventos de riscos, preciso determinar o quanto est em jogo e quanto crtico isso se torna. Lembre que essas duas variveis podem ser alteradas com o tempo, dependendo do estgio da vida cclica do projeto. Na maioria dos casos, a quantidade em jogo e a criticalidade podem ser alcanadas por um simples exame de informaes disponveis e um julgamento subjetivo. Porm, em situaes complexas, pode ser necessrio desenvolver algum tipo de modelo matemtico, construir e executar uma srie de anlises geradas por um computador.

Criando uma Matriz de Assimilao de riscos

Uma serie de concluses e recomendaes devem ser desenvolvidas para que as decises de gerenciamento apropriadas possam ser realizadas com base em todos conhecimentos envolvidos com o risco.

Agrupar riscos por severidade e probabilidade torna essa tarefa muito mais fcil de ser alcanada. Usando uma matriz como a mostrada abaixo, podemos identificar riscos que tem alta probabilidade e alto impacto, riscos com probabilidade alta e impacto baixo, riscos com probabilidade baixa e impacto alto e riscos com probabilidade baixa e impacto baixo.

Tabela

Uma anlise desses agrupamentos ajudar a determinar quais riscos apresentam oportunidades a serem almejadas e quais apresentam ameaas a serem controladas. Qualquer risco que for aceito ou ignorado deve ser documentado junto com a pessoa ou grupo responsvel por tomar as decises. Essa matriz deve tambm incluir um ranking de preciso. A preciso refere-se ao grau de entendimento do risco. Similar aos rankings de impacto e probabilidade, o ranking de preciso deve ser feito baseado numa escala de impreciso, moderado ou preciso.

Lio 22: Desenvolvimento de Respostas aos Riscos e Controle das Respostas

Objetivos da Lio: Os sub-processos de desenvolvimento e controle de respostas aos riscos envolvem estabelecer e manter informaes sobre o status do risco, definir planos de aes e agir em cima dessas informaes. Os elementos essenciais do controle e acompanhamento dos riscos so muito parecidos com os processos equivalentes dos modelos tradicionais de gerenciamento de projetos e podem ser facilmente integrados aos processos de acompanhamento e controle. At o final dessa lio voc deve estar apto a: Aplicar aquisio como uma resposta aos riscos Entender o planejamento de contingncias Utilizar estratgias alternativas Avaliar seguros como uma resposta aos riscos Explicar o princpio de desvios como uma maneira de controle das respostas

aos riscos Termos Chave Plano de Gerenciamento de Riscos Identificao de Riscos Quantificao de Riscos Planejamento das Contingncias Desvios Premissas de Riscos

Viso Geral Respostas aos riscos e controle das respostas incluem a definio de polticas, metas e padres de responsabilidade para o gerenciamento do risco no projeto. Quando apropriado, a poltica de risco deve ser baseada sobre o principio de que a responsabilidade est sobre aqueles que representam a fonte de risco em um determinado evento. A seleo da estratgia mais adequada para mitigar o risco deve mover o evento de risco de incerto para certo ou a probabilidade do evento

acontecer deve diminuir de alta para media ou de media para baixa. Uma estratgia inclui fazer nada, caso a probabilidade de ocorrncia seja baixa. Qualquer que seja a estratgia, as seguintes atividades so necessrias: Identificar as atividades que previnem o risco Fornecer as informaes de riscos para outros processos Desenvolver o plano de gerenciamento dos riscos Implementar o plano de gerenciamento dos riscos para os eventos de riscos

que ocorrerem Identificar e planejar os riscos no antecipados Revisar o plano de respostas com as partes interessadas afetadas Tomar aes preventivas

Identificando as Atividades de Preveno dos Riscos O propsito do gerenciamento dos riscos realizar aes que reduzam o risco e faam o risco desaparecer. Existem 3 mecanismos alternativos de respostas para lidar com riscos. O primeiro evitar, tambm conhecimento como abatimento do risco. Essa estratgia reduz a possibilidade do risco ocorrer. A prxima a mitigao do risco. As atividades envolvidas nesse mecanismo reduzem as conseqncias do risco caso ele ocorra. Finalmente, existe a aceitao do risco, em outras palavras, entubar. Essa alternativa uma deciso consciente de aceitar as conseqncia do risco e simplesmente ignor-lo. Desenvolver respostas aos riscos exige, primeiramente, estabelecer o sistema estratgico apropriado, depois pegar seguros para aqueles riscos possveis e planejar aes especificas para lidar com os riscos que sobraram. Esses ltimos podem variar desde decises simples de aceitar os riscos como eles esto, especialmente em projetos pequenos, at um abrangem plano de uso de recursos para controlar um evento de risco, caso ele ocorra, quando esse evento de algo impacto ou urgente. A equipe do projeto normalmente possui vrias opes para respondes aos eventos de riscos. Aquisies como a compra de produtos ou servios de outras empresas so uma boa resposta para alguns tipos de riscos. No entanto, aquisies normalmente envolvem trocar um risco por outro (por exemplo, mitigar o risco de custos com um contrato com o preo fixado pode criar um risco no cronograma caso o contratado no consiga entregar a tempo). Planos de contingncia delineiam os passos a serem tomados caso um risco identificado ocorra (mitigao de riscos). Estratgia alternativas podem permitir que eventos de riscos possam ser prevenidos ou evitados mudando a abordagem inicial planejada. Vrias reas de aplicao possuem um vasta literatura sobre o valor potencial de vrias estratgias alternativas (abatimento dos riscos). Seguros ou qualquer tipo de acordo do gnero so possveis para apenas algumas categorias de riscos. O tipo de cobertura disponvel e os custos variam de setor para setor. A equipe do projeto deve considerar todas as suas opes e selecionar aquela

que ira melhor eliminar o evento de risco ou reduzir a conseqncia de sua ocorrncia. As alternativas desenvolvidas, incluindo as que foram selecionadas e as que foram excludas, devem ser documentadas junto com as premissas usadas para a tomada de decises e a pessoa responsvel por isso. Fornecendo as Informaes de Riscos para os Outros Processos Como um resultado das estratgias de respostas aos riscos, os processos de planejamento podem ter que ser modificados vrias vezes at que o plano do projeto possa ser finalizado. Aqueles no comando do planejamento deve reconsiderar os elementos que forem afetados pelo plano de respostas. Por exemplo, a deciso de comprar algum bem ou servio de outras empresas pode requisitar planos adicionais de aquisies. De modo parecido, desenvolver estratgia alternativas de respostas para os evento de riscos pode estender a durao do projeto e podem necessitar mudanas no cronograma do projeto. Resumidamente, uma vez que os efeitos das respostas planejadas so identificados, os processos de planejamento que foram afetados devem ser revisados e as mudanas necessrias devem ser feitas. Para fornecer informaes para outros processos gerenciais deve-se: afetam lidados Um bando de dados de riscos sobre eventos de riscos e maneiras de mitig-los pode ser buscado para gui-lo durante os passos acima. Desenvolvendo um Plano de Gerenciamento dos Riscos Um plano de gerenciamento dos riscos um declarao da poltica geral que define os procedimentos de gerenciamento dos riscos de um projeto. O plano deve incluir uma lista completa de todos os riscos identificados, assim como as aes planejadas e as respostas para cada um deles. Os indivduos responsveis para lidar com cada evento de risco tambm devem ser documentados. O plano deve tambm definir procedimentos para identificar e responder aos eventos de riscos adicionais que surgiram ao longo do projeto. Implementando o Plano de Gerenciamento de Riscos para os Eventos de Riscos que Ocorrerem Algumas reas de risco so antecipadas durante o processo original de planejamento e aes preventivas e contingenciais so adicionadas ao plano de gerenciamento de riscos. Aes preventivas so retro alimentadas no plano do projeto e no cronograma como atividades adicionais. De outro lado, as aes contingenciais so acionadas por eventos de riscos que ocorrem de verdade e so Determinar os potencias impactos das reas de risco e evento e fazer as Estimar quais elementos do plano do projeto as varias respostas aos riscos

mudanas necessrias nessas reas Garantir que todos os riscos identificados foram devidamente avaliados e

feitas para mitigar o impacto negativo nos objetivos do projeto assim que o risco se materializa. Para implementar o plano de gerenciamento de riscos deve-se: Identificar a ocorrncia de algum evento de risco de verdade que foi

planejado no plano de gerenciamento de riscos Decidir se a ao contingencial planejada ainda apropriada e modific-la

quando necessrio Comunicar a ocorrncia de um evento de risco e a ao planejada para as

partes interessadas afetadas Tomar a ao contingencial e monitorar os resultados

Identificando e Planejando os Riscos no Antecipados Vrios riscos no podem ser antecipados, devido a circunstancias novas, mas devem ser compreendidos e planejados assim que eles forem identificados. Novas reas de risco que forem identificadas devem ser quantificadas e a resposta deve ser desenvolvida. Por exemplo, uma pessoa contratada pode estar tendo problema em se manter dentro do cronograma dos entregveis como originalmente planejado. Aes podem ser planejadas para proativamente prevenir o contratado de se atrasar, como fornecer recursos adicionais para ele. Outras aes podem ser planejadas para quando se perceber claramente que o contratado no vai conseguir entregar a tempo, como o cancelamento do contrato ou contratar outra pessoa para completar o trabalho. Para identificar e planejar riscos no antecipado a equipe do projeto deve realizar as seguintes 4 tarefas: Identificar as fontes adicionais de riscos para o projeto que no foram

planejadas no plano de gerenciamentos dos riscos original Estimar a probabilidade de ocorrncia e os potenciais impactos da ocorrncia

do risco para entender sua importncia para o projeto Definir as aes preventivas e contingenciais mais apropriadas para evitar

ou mitigar o impacto do risco Designar responsveis pelas aes relacionadas aos riscos

Revisando os Planos de Respostas com as Partes Interessadas Afetadas As partes interessadas afetadas do projeto devem ser imediatamente avisadas sobre novas reas de riscos identificadas. Quando os riscos so improvveis ou sua ocorrncia remota, a equipe pode escolher esperar para ter mais informaes antes de avisar as partes interessadas. Quando os riscos tem uma maior chance de ocorrer ou seu impacto potencialmente grande, as partes interessadas devem ser ativamente envolvidas no planejamento e na tomada de decises. Para revisar os planos de respostas com as partes interessadas afetadas deve-se: Determinar o nvel de envolvimento necessrio das partes interessadas na

quantificao e planejamento do risco

Informar as partes interessadas sobre novos riscos identificados e os planos

de respostas Envolver as partes interessadas na quantificao e planejamento do riscos

at quando for preciso Documentando Aes e Atualizando Planos Todas as aes tomadas em respostas a um rea de risco devem ser documentadas como parte do arquivo do projeto. Aes preventivas e contingenciais planejadas para novas reas de riscos identificadas so usadas para atualizar o plano de gerenciamento dos riscos e mant-lo assim. Aes preventivas devem ser includas como novas atividades no cronograma do projeto da mesma maneira que as atividades originais foram definidas, seqenciadas e estimadas. Para documentar as aes e atualizar os planos deve-se: Documentar todas as aes tomadas em respostas a riscos antecipados,

junto com os resultados dessas aes, e depois inclu-las ao arquivo do projeto Definir as atividades envolvidas nas aes preventivas planejadas para

novos riscos identificados Identificar as dependncias das atividades e seu seqenciamento nas aes

preventivas Estimar a durao das aes preventivas Estimar os recursos adicionais que sero necessrios e os custos, caso

exista, das aes preventivas Atualizar o cronograma do projeto e os documentos relacionados com as

estimativas de todas as aes preventivas Atualizar o plano de gerenciamento dos riscos com as aes preventivas e

contingenciais Tomando Aes Preventivas J que as aes preventivas so tomadas proativamente para prevenir a ocorrncia de um evento de risco real, elas devem ser executadas de acordo com o cronograma atualizado do projeto como um atividade qualquer. Para tomar aes preventivas deve-se: Revisar o cronograma atualizado do projeto com a equipe e garantir que os

responsveis pelas atividades foram definidos para todas as aes preventivas Executar as aes preventivas Relatar o progresso de todas as aes preventivas