Apostila Gerencia Escopo Magno FGV

7/27/2019 Apostila Gerencia Escopo Magno FGV

1/80

MBA em Gerncia de Projetos

GERNCIA DE ESCOPO EMPROJETOS

Carlos Magno da Silva Xavier

(M.Sc., PMP)[email protected]

RealizaoFundao Getulio VargasFGV Management


2/80

Sumrio

1.PROGRAMADADISCIPLINA 1

1.1EMENTA 11.2CARGA HORRIA TOTAL 11.3OBJETIVOS 11.4CONTEDO PROGRAMTICO 11.5METODOLOGIA 21.6CRITRIOS DE AVALIAO 21.7BIBLIOGRAFIA RECOMENDADA 2

CURRICULUM RESUMIDO DO PROFESSOR 2

2 TEXTO PARA ESTUDO 3

2.1INTRODUO 32.2GERENCIAMENTO DO ESCOPO DO PROJETO 72.2.1 INICIANDO O PROJETO 92.2.2 DEFININDO O ESCOPO DO PROJETO 17

2.3.3 CRIANDO A ESTRUTURA ANALTICA DO PROJETO 212.3.4OBTENDOAACEITAODOESCOPO 352.3.5 CONTROLANDO O ESCOPO DO PROJETO 37

3 MATERIAL COMPLEMENTAR 40


3/80

1

1. Programa da disciplina

1.1 Ementa

Iniciao. Project Charter. Planejamento de escopo. Deliverables. Definio deobjetivos. WBS - Work Breakdown Structure. Detalhamento do escopo.Verificao e acompanhamento do escopo. Controle de mudanas no escopo.

1.2 Carga horria total

24 horas / aula

1.3 Objetivos

Apresentar as tcnicas e padres para definir, planejar, detalhar, verificar egerenciar o escopo em projetos

1.4 Contedo programtico

Iniciando o projeto Processo de formalizao do incio do projeto Project Charter

Definindo o escopo do projeto

Declarao de Escopo (scope statement)Criando a Estrutura Analtica doProjeto

Processo de detalhamento do escopo Estrutura Analtica do Projeto (WBS) Subprodutosdo projeto (Deliverables)

Obtendo a aceitao do escopodo projeto

Processo de obteno do aceite do escopo

C l d d j


4/80

2

1.5 Metodologia

Exposio da teoria entremeada por debates, estudos de caso, exerccios e relatosda vivncia profissional.

1.6 Critrios de avaliao

A avaliao acadmica ser efetuada atravs de uma prova (60%) e trabalho

(40%).

1.7 Bibliografia recomendada

Xavier, Carlos Magno - Gerenciamento de Projetos Como definir e controlar oescopo do projeto. So Paulo: Editora Saraiva, 2005.

Xavier, Carlos Magno (co-autor) Metodologia de Gerenciamento de Projetos

Methodware.Rio de Janeiro: Brasport, 2005.PMI, Project Management Institute (Editor). Um Guia do Conjunto deConhecimentos do Gerenciamento de Projetos - PMBOK(Project Management

Body of Knowledge) Guide. PMI, 2004

Curriculum resumido do professor

Carlos Magno da Silva Xavier mestre em Sistemas e Computao peloInstituto Militar de Engenharia (IME). Scio-Diretor da Beware ConsultoriaEmpresarial Ltda. Sua experincia profissional, de mais de quatorze anos em gernciade projetos, inclui o cargo de Chefe do Departamento de Sistemas de Informao da

Diretoria de Administrao da Marinha, responsvel pela conduo da informtica

corporativa utilizada para fins administrativos da Marinha Brasileira, assim como adocncia e consultoria em gerncia de projetos. Autor dos livros Projetando comQualidade a Tecnologia em Sistemas de Informao, LTC Livros TcnicosCientficos e Gerenciamento de Projetos Como definir e controlar o escopo do

projeto Editora Saraiva, e co-autor dos livros Como se tornar um profissional emGerenciamento de Projetos, Qualitymark Editora, e Metodologia de Gerenciamentode Projetos Methodware Brasport certificado Project Management


5/80

3

2. TEXTO PARA ESTUDO

2.1 Introduo

O Gerenciamento de Projetos (GP) um ramo da Cincia daAdministrao que trata do planejamento, execuo e controle de projetos. Em ummercado com dezenas de ofertas para cada tipo de produto, o cliente que dita osucesso das empresas e isto tem levado as organizaes a viverem em permanenteestado de mudana, seja lanando um novo produto ou melhorando o atual, sejaefetuando uma ampliao ou modificao na linha de produo, seja efetuandomudanas administrativas. Todas as mudanas visam a tornar a empresa maiscompetitiva. Cada mudana um empreendimento ou projeto, ou seja, um esforo

temporrio (possui data de incio e de trmino) que tem por finalidade produzir um bem(produto ou servio) com caractersticas peculiares que o diferenciam de outros que,eventualmente, j tenham sido produzidos.Assim sendo, navegar na arena de negciosexige, atualmente, o domnio das mais modernas metodologias de Gerenciamento deProjetos.

Um cruzeiro no oceano um excitante passeio Ao embarcar voc vai aos

EFETIVOS E BEM SUCEDIDOS GERENTESDE PROJETOS SO COMO MESTRES DEUMA BATERIA DE ESCOLA DE SAMBA,QUE NO NECESSITAM TOCAR TODOSOS INSTRUMENTOS, MAS DEVEM OBTERO MELHOR DE SEUS ESPECIALISTAS


6/80

4respostas diretas. Mas o seu desconhecimento no elimina os riscos. O seu

planejamento e controle do projeto iro determinar se voc ir afundar ou nadar.

Executar projetos uma caracterstica de sobrevivncia da empresa moderna.Saber planejar e executar projetos uma necessidade real de qualquer executivo. Oassunto to importante que vrias organizaes se especializaram na gerncia de

projetos. O novo ambiente de negcios, caracterizado por uma grande pulverizao deequipes, cada vez mais distantes geograficamente, apresenta um grande desafiogerencial na integrao dessas diversas equipes de pesquisadores, inovadores,

estudantes, professores, facilitadores (drivers), fornecedores, fabricantes, engenheiros,projetistas, analistas, financiadores, bem como outros intervenientes para a realizao deprojetos, com objetivos claros, recursos materiais / financeiros limitados, e princpio,meio e fim bem definidos. A resposta a esse desafio passa pelo desenvolvimento deTcnicas, Metodologias, Tecnologias e asBest Practices de Gerenciamento de Projetos(Project Management).

Uma metodologia formal de gerenciamento de projeto habilita a empresa amaximizar a consistncia, eficincia, qualidade e produtividade em projetos. Segundo oStandish Group, em seu relatrio Extreme CHAOS2001, graas ao uso de melhoresmtodos de gerenciamento, o percentual de sucesso em projetos nos EUA cresceu de34% em 1994 para 55% em 2000, o que pode ser verificado no grfico da figura abaixo.

Evoluo do sucesso e fracasso

em projetos

20000

40000

60000

80000

100000

120000

140000

160000

Projetos que

obtiveram

sucesso

Projetos quefracassaram

Total de

Projetos


7/80

5

O PMI - Project Management Institute - hoje a organizao lder emGerenciamento de Projetos em todo o mundo. Criado nos EUA (Pensilvnia) em 1969, uma instituio sem fins lucrativos dedicada ao avano do estado-da-arte emgerenciamento de projetos e seu principal compromisso "promover o profissionalismoe a tica em gesto de projetos". Atualmente, o PMI est representado no Brasil pelasseguintes sees regionais (Chapters): So Paulo, Rio de Janeiro, Distrito Federal, RioGrande do Sul, Paran, Minas Gerais, Pernambuco (potencial), Bahia (potencial),Joinville & Florianpolis (Potencial), Mato Grosso do Sul (potencial) e Amazonas

(potencial). (mais detalhes podem ser obtidos nosite do PMI em www.pmi.org.).Em agosto de 1987, o PMI publicou um documento denominado The Project

Management Body of Knowledge. Este documento foi revisado e republicado em 1996,com o nome de A Guide to the Project Management Body of Knowledge (PMBOK)1,tendo sido atualizado em 2000 e 2004. Esse guia reflete 30 anos de experincia obtidosem gerenciamento de projetos, desde os seminrios organizados na dcada de 60 peloDepartamento de Defesa (DoD), NASA e outras organizaes governamentaisamericanas. O PMBOK sugere quais processos devem ser executados, durante ogerenciamento de projetos, nas reas de Escopo, Tempo, Custo, Recursos Humanos,Comunicaes, Risco, Aquisies e Qualidade, propondo tambm um conjunto de

processos para a integrao dessas reas. Ele, portanto, apresenta o o que deve serfeito, mas no o como implementar esses processos.

A importncia do gerenciamento de escopo pode ser verificada no resultado dapesquisa realizada pela gantthead.com em agosto de 2003 que levantou as dez maiores

i d j t d t l d t d

AquisiesAquisies

CustoCusto TempoTempo

QualidadeQualidadeEscopoEscopo

RHRH

RiscosRiscos

ComunicaoComunicaoAquisiesAquisies

CustoCusto TempoTempo

QualidadeQualidadeEscopoEscopo

RHRH

RiscosRiscos

ComunicaoComunicao

INTEGRAOINTEGRAO


8/80

66. Estimativas de esforo pobres;

7. Falta de alinhamento cultural e tico;8. No alinhamento entre a equipe do projeto e o negcio ou outra organizaocliente;

9. Mtodos inadequados ou mal empregados; e10. Comunicao inadequada, inclusive acompanhamento e relato de progresso.

Da mesma forma, o Estudo de Benchmarking em Gesto de Projetos 2004,

iniciativa pioneira do Project Management Institute do Rio de Janeiro, revela que asmudanas constantes de escopo, escopo do projeto com nvel de detalhe insuficiente,produtos mal especificados e expectativa do cliente desalinhada com a realidade doprojeto so problemas freqentes enfrentados em projetos, conforme pode ser visto nafigura abaixo.

Esta disciplina pretende apresentar aos alunos como deve ser definido econtrolado o escopo em um projeto.


9/80

7

2.2 Gerenciamento do Escopo do Projeto

Quando voc vai gerenciar um projeto, um grande desafio definir claramenteos produtos e / ou servios, relacionados aos objetivos do projeto, que sero entreguesao patrocinador / cliente, estabelecendo o escopo do trabalho que deve ser realizado pelaequipe do projeto para a gerao dos mesmos. Esses produtos / servios, algumas vezeschamados de entregas, so usualmente denominados deliverables (subprodutos,resultados principais, entregveis ou entregas) pela comunidade de gerenciamento de

projetos. O PMBOK define deliverables como: qualquer resultado mensurvel,tangvel e verificvel que deve ser produzido para completar o projeto ou parte dele.

A definio do escopo em um projeto no uma necessidade dos tempos atuais.Veja, por exemplo, o escopo do projeto de construo de uma cidade romana, que apresentado abaixo.

"A MATURIDADE EM GERENCIAMENTO DEPROJETOS DE UMA ORGANIZAO PROPORCIONAL A SUA HABILIDADE EMREALIZAR OS PROCESSOS NECESSRIOS CONDUO DE SEUS PROJETOS, SENDO

FUNDAMENTAL A EXISTNCIA DEPADRES, MTRICAS E CONTROLES,ASSIM COMO O APERFEIOAMENTOCONTNUO DESSES PROCESSOS


10/80

8

importante neste momento diferenciarmos Escopo do produto de Escopo doProjeto. Enquanto o primeiro est relacionado ao conjunto de caractersticas e funesque o produto final deve possuir, o segundo est relacionado ao trabalho que deve serrealizado para que seja entregue o produto final do projeto, com as caractersticas efunes definidas para o mesmo. O trabalho do projeto consiste na gerao e entrega de

produtos e servios. Enquanto o escopo do produto representado em documentoscomo requisitos, especificaes, desenhos etc., o escopo do projeto representado naEstrutura Analtica do Projeto (WBS), a ser vista no processo de definio de escopo,

que contm os deliverables (subprodutos) que devem ser gerados no projeto.Por exemplo, se o projeto de desenvolvimento de um sistema de informao, o

escopo do produto representado em uma Especificao do sistema. O escopo doprojeto (representado na WBS) consiste no conjunto de subprodutos (produtos eservios) que devem ser gerados para que o sistema de informao seja entregue. AWBS conter, alm do prprio sistema que ser desenvolvido, os subprodutosnecessrios ao gerenciamento do projeto (plano do projeto, relatrios etc.), documentosdo sistema, testes, treinamento de usurios, podendo incluir a montagem do ambiente de

desenvolvimento (hardware e software), treinamento do pessoal de desenvolvimentoetc. A figura abaixo compara o escopo do produto com o escopo do projeto.

Escopo do Produto Escopo do Projeto

As caractersticas ou funesque devem ser includas no

produto ou servio

O conjunto de produtos eservios (deliverables) que

devem ser gerados pelo projetoREQUISITOS /ESPECIFICAES WBS

X


11/80

9

2.2.1 Iniciando do ProjetoO escopo do projeto comea a ser delineado quando da concepo, seleo e

iniciao do projeto.

Digamos que voc tenha acabado de receber uma herana de R$ 500.000,00. Oque voc faria com esse dinheiro? Com certeza muitos projetos esto passando por suacabea. Comprar um imvel? Montar uma empresa? Viajar? Construir uma casa? Pagar

dvidas? Investir tudo em um nico projeto? Investir em um portflio (carteira deprojetos)? Como selecionar entre tantos possveis projetos? Como definir o queexatamente esperar de cada um dos projetos que decida investir?

As empresas, normalmente, precisam tomar as mesmas decises que voc nopargrafo acima. Elas no recebem heranas, mas tm oramentos para enquadrar osinvestimentos em projetos ou, algumas vezes, precisam obter financiamentos paraviabilizar esses projetos. Mesmo as empresas prestadoras de servios, cujo dia-a-dia

executar projetos, tambm precisam ter seus procedimentos para decidir apresentar ouno propostas a seus clientes e, se for o caso, como elabor-las.

Para o processo de seleo de projetos, cada empresa tem os seusprocedimentos. Vejamos abaixo alguns exemplos:

Exemplo 1: A empresa tem um Comit que aprova os investimentos e todos osnovos projetos so submetidos a ele. Participam do comit normalmente todosos diretores da empresa.O documento levado bem resumido e objetivo, mascontempla o que necessrio para uma tomada de deciso. O documento ainda associado ao BSC (Balanced Score Card) da rea e mostra claramente comoajudar com cada indicador. O BSC uma tcnica que visa integrao e

balanceamento de todos os principais indicadores de desempenho existentes emuma empresa, desde os financeiros / administrativos at aos relativos aos

processos internos, estabelecendo objetivos da qualidade (indicadores) parafunes e nveis relevantes dentro da organizao, ou seja, desdobramento dosindicadores corporativos em setoriais, com metas claramente definidas.

Algumas informaes contidas nesse documento em que o projeto submetidoao Comit so:

o Lista de Objetivos do Projeto;o Lista de Indicadores (BSC) atingidos pelo Projeto;o Lista de Processos e Funes do Negcio tratadas pelo Projeto;


12/80

10o Principais Marcos (pontos de controle do projeto).

Exemplo 2: A empresa, no processo de autorizao de projetos realiza asseguintes atividades:

o Alinhamento com o Business Case so estabelecidos os critrios"direcionadores" do projeto que podem ser: custo / benefcio; qualidade(em relao ao produto, ao servio, aos canais de distribuio ou operao); requisitos de auditoria ou de melhorias de controles;requisitos legais; e iniciativas estratgicas.

o Estudo de viabilidade avaliao da viabilidade tcnica e econmica doprojeto, onde os riscos so tambm levados em considerao;

o Elaborao do documento de definio do projeto;o Apresentao para o Comit de avaliao de projetos; eo Priorizao do projeto, com a designao dosponsor(patrocinador) e do

gerente do projeto.

Exemplo 3: Em uma empresa prestadora de servios, quando chega uma

demanda, verificado inicialmente se a mesma faz parte do core business. Casofaa parte, antes de comear o processo de elaborao de uma proposta, estima-se o esforo para elabor-la, ou seja, o departamento tcnico especialista nademanda faz a estimativa. Baseado nessa estimativa, a rea de vendas estima ocusto desse esforo. Este custo apresentado alta administrao para verificarse vivel ou no tratar essa demanda. Se for vivel, autorizada a elaboraoda proposta. A proposta deve ser feita, em conjunto, pelas reas tcnica ecomercial. Caso a proposta seja aprovada pelo cliente e o contrato assinado

(quando couber), designado um gerente do projeto.

Exemplo 4: Em uma empresa cujos projetos de TI (Tecnologia da Informao)so internos, principalmente para a criao de novos produtos para seusclientes, o primeiro passo a apresentao da proposta, com a estrutura,arquitetura e prazo, para um comit chamado de CRP (Comit Revisor deProjetos). Nesse Comit so discutidas, com todos os responsveis por reas deTecnologia da Informao e Infra-estrutura de todas as Business Units da

empresa, as propostas de mudanas na soluo apresentada, idias defornecedores, arquiteturas diferentes e realizadas trocas de experincias sobre omesmo tema. Aps essa reviso da proposta de projeto, elaborado umdocumento chamado Planilha de Avaliao de Projeto, que levado ao CAIS(Comit de Avaliao de Investimentos em Sistemas). Esta planilha mostra ofluxo de caixa do projeto, indicadores BSC que sero afetados pelo sistema,B k E t etc Esse comit q em d o GO (a tori ao) o NO GO do


13/80

11Integrao do Projeto pois, alm do escopo, leva em considerao questes relativas a

tempo, custo, risco, recursos humanos, comunicao, aquisies e qualidade.

Na maioria das organizaes, um projeto no formalmente iniciado at quetenha a avaliao de sua real necessidade, estudo de visibilidade ou planejamento

preliminar. Esta fase inicial de concepo pode e deve ser considerada como um projetoespecfico, cujo objetivo demonstrar para a organizao que o projeto necessrio evivel.

Mtodos de seleo de projetosNormalmente, vrios projetos concorrem pela utilizao de recursos dentro de

uma empresa. Para selecionarmos que projetos devem ser executados, devemos levarem considerao as necessidades da empresa, normalmente espelhadas em seu planoestratgico, estabelecendo critrios consistentes e lgicos de avaliao que iro

possibilitar o processo de priorizao e seleo dos projetos.

Os critrios de seleo so, tipicamente, definidos em termos dos mritos doproduto do projeto, tais como: retorno financeiro, anlise de custo-benefcio, aumentoda participao no mercado, melhoria da imagem da empresa, transferncia detecnologia, satisfao do cliente etc. A estimativa de custo e os conceitos financeirosutilizados na comparao / anlise financeira de projetos (Taxa Interna de Retorno,Prazo para pagamento do retorno, Valor Presente, Valor presente lquido etc.) serovistos mo mdulo de Gerenciamento de Custo.

Com os critrios estabelecidos necessrio utilizar algum mtodo de seleo de

projetos, os quais tambm podem ser utilizados na comparao de alternativas paraexecutar o projeto, o que faz parte da Definio do Escopo. Os mtodos de seleo de

projetos mais utilizados so os de medio dos benefcios abordagens comparativas,modelos de pontuao (scoring model), contribuio para os benefcios ou modeloseconmicos.

Um exemplo de seleo de projetos, utilizando o modelo de pontuao pode serverificado no quadro abaixo, em que trs projetos (A, B e C) esto sendo comparados

utilizando-se os critrios de retorno financeiro, aumento da participao no mercado,melhoria da imagem da empresa, utilizao da capacidade ociosa da empresa edesenvolvimento de novas tecnologias. Para cada um dos critrios atribudo um peso,de acordo com a importncia estratgica do critrio para a empresa.

O critrio mais importante deve receber o peso 10 e os demais recebem pesoi i j li d d i i f


14/80

12

Critrios Peso NotasProjeto A

NotasProjeto B

NotasProjeto C

Retorno financeiro 10 10 8 6

Aumento da participao no mercado 8 7 10 8

Melhoria Imagem da Empresa 7 8 9 10

Utilizao de capacidade ociosa 7 6 9 10

Desenvolvimento de novastecnologias

4 10 8 6

Pontuao final de cada projeto 294 318 288

Temo de Abertura do Projeto (Project Charter)

O Project Charter o documento que autoriza formalmente o incio de um

projeto. a partir da emisso dele que a empresa divulga internamente que um projetoexiste e qual a sua finalidade. A traduo oficial do PMBOK para Project Charter Termo de Abertura do Projeto. Vemos porm outros nomes para esse documento sendoaplicados em empresas ou sugeridos na literatura, entre eles:

Termo de Referncia do Projeto; Documento de Autorizao do Projeto; Documento Inicial do Projeto;

Documento de Abertura do Projeto; Autorizao de Incio do Projeto; Proposta de Projeto Aprovada; Carta do Projeto; e Mapa do Projeto.

Segundo Kerzner, o conceito original do Project Charter era somentedocumentar a autoridade e responsabilidade do gerente de projeto. Esse conceitoevoluiu e o project charter transformou-se em um documento interno pelo qual aempresa reconhece e comunica o escopo aprovado do projeto aos gerentes funcionais,ou de linha, e seu pessoal, como uma espcie de "contrato" entre o gerente de projeto ea empresa, tendo como testemunhas os gerentes funcionais. Por esse enfoque, o projectcharterpode estabelecer tanto as responsabilidades do gerente de projeto quanto dosgerentes funcionais.


15/80

13 Requisitos que satisfazem as necessidades, desejos e expectativas do

cliente, do patrocinador e de outras partes interessadas Gerente de projeto designado e nvel de autoridade atribuda Cronograma de marcos sumarizado Influncia das partes interessadas Organizaes funcionais e sua participao Premissas Restries Referncia ao Estudo de viabilidade (Business Case) justificando o

projeto, incluindo o retorno sobre o investimento Oramento sumarizado.

As necessidades do negcio que o projeto est incumbido de atender, quejustificam que o projeto seja autorizado

necessrio fazer o alinhamento do projeto com os objetivos estratgicos daempresa. Por que o projeto foi autorizado? Quais so os resultados esperados com aentrega do(s) produto(s) do projeto? Um exemplo de alinhamento do projeto seria:

Dada a constante diminuio dos espaos fsicos nas modernas habitaes, estratgico para a empresa Bicicleta S.A. que seja a primeira empresa a desenvolveruma bicicleta capaz de ser guardada de tal modo que ocupe o menor espao fsico

possvel, criando-se assim um novo segmento de bicicletas. O fato de ser o primeironeste novo segmento proporcionar a fixao da marca, o domnio deste mercado e aexpanso nos demais segmentos de mercado de bicicletas.

Requisitos que satisfazem as necessidades, desejos e expectativas do cliente, dopatrocinador e de outras partes interessadas (descrio do produto do projeto)

A descrio do produto documenta as caractersticas do produto ou servio que oprojeto est incumbido de criar. Vale ressaltar, porm, que devem ser relacionadostodos os produtos e servios que o projeto deve entregar para satisfazer as necessidades,desejos e expectativas do cliente. Se o projeto de um novo carro, pode fazer parte do

produto do projeto, alm de gerar um prottipo, desenhar o ferramental para a

fabricao do carro, modificar a linha de produo e, at mesmo, a campanhapromocional de lanamento. Um exemplo de descrio de produto seria:

Fabricao, fornecimento, montagem e comissionamento de uma PequenaCentral Hidreltrica (PCH) de 10 MVA a 13,8 KV, com uma turbina tipo Francis,conforme especificada no edital n 1234/2004 do Governo do Estado H2O, a serinstalada na Usina de Acar e lcool XPTO Ltda no m nicpio XYZ m contrato


16/80

14

A gerente deste projeto ser a Sra Leila, que tem autoridade para utilizar osrecursos financeiros da empresa at o limite do oramento aprovado para este projeto,podendo recrutar pessoal em todos os departamentos da empresa ou at admitirfuncionrios novos (quadro provisrio, com prazo determinado at o trmino do

projeto), alm de poder comprar ou alugar equipamentos e peas, desde que dentro daprogramao financeira do projeto.

Restries

So fatores que limitam as opes da equipe de gerenciamento do projeto.Quando um projeto executado sob contrato, as clusulas contratuais geralmente seconstituiro em restries ao projeto.

Normalmente, as restries principais so:

Tempo, tais como datas fixas, de incio e / ou de trmino, ou um prazo para aconcluso do projeto e / ou de uma de suas fases intermedirias;

Recursos fsicos, tais como materiais, instalaes, equipamento e pessoal; e Custo, como um oramento predefinido.

Alguns exemplos de restries so:

O projeto de reforma dever ser conduzido com o laboratrio emfuncionamento, sem afetar o processo de anlise de controle de qualidade, queno ser interrompido;

Prazo de 90 dias a partir da aprovao do projeto bsico para elaborao doProjeto Executivo da nova Pista de Pouso e Decolagem; O projeto tem um prazo total de 12 meses, sendo que no final do primeiro ms

devero ser iniciados os trabalhos de construo no campo; A verba do oramento a ser utilizada nesse projeto de um milho e quinhentos

mil reais (R$ 1.500.000,00), no podendo ultrapassar 10% desse valor noprimeiro ms;

Todos os funcionrios devero ser treinados em cursos de segurana ministrados

pela prpria Usina e participar durante 10 minutos do DDS (Dialogo Dirio deSegurana) ministrado por Tcnicos de Segurana contratados na obra; e Os servios s podero ser executados de 2 a 6 feira das 9:00 s 18:00 horas.

Deve-se ter cuidado de no utilizar as restries do projeto para limitar o escopodo produto do projeto. Caso seja necessria, essa limitao deve ser colocada na prpriadescrio do prod to Os e emplos abai o no so restries ao projeto mas sim ao


17/80

15- Para aquisio do software ser necessria uma pesquisa de mercado, para se

verificar se h no mercado a existncia de algum que venha a atender snecessidades do projeto; e- O novo ptio de pouso e decolagem a ser dimensionado ter, aproximadamente,

31.750,00 m2.

Premissas (hipteses, suposies)

So fatores que, para fins de planejamento, so considerados como verdadeiros,reais ou certos. Embora o termo comumente empregado no Brasil seja premissa(traduo oficial do PMBOK para assumption), o termo em portugus mais adequado hiptese. Normalmente as hipteses redundam em um certo grau de risco (ameaas ouoportunidades) para o projeto, sendo levadas em considerao quando do gerenciamentode riscos do projeto.

Durante o estgio de planejamento de um projeto, voc provavelmente termuitas perguntas importantes sem resposta; por exemplo, quando os recursos-chaveestaro disponveis para iniciar o trabalho e quanto tempo um novo processo levar?

Para iniciar o planejamento, voc far algumas suposies (hipteses) e as usar paracriar sua agenda. importante levantar as hipteses para que:

Voc possa atualizar o planejamento quando tiver informaes adicionaissobre esses fatores;

Caso o seu projeto dependa do trabalho de terceiros (resultados de outrosprojetos, departamentos ou at mesmo do cliente), eles compreendamessa dependncia e concordem com as datas de entrega previstas; e

Possa levar em conta a disponibilidade de recursos (incluindo pessoas,materiais e equipamentos): se voc no o gerente de algumas daspessoas que trabalharo no projeto, quem as gerencia? E essa pessoaaprovar o uso desses recursos por voc?

Alguns exemplos de premissas so:

o Sero disponibilizados cinco Analistas da rea de Recursos Humanos

em perodo integral e trs analistas da rea de Tecnologia daInformao em perodo part time (um Analista de Processos, umAnalista de Microinformtica e uma Analista de Sistemas);

o O cliente disponibilizar at o dia 01/02/2005 toda a infra-estrutura dehardware e software necessria para o desenvolvimento e instalao dosistema;O Cliente ir re isar e retornar ao Gerente de Projetos os doc mentos


18/80

16o O local de instalao do equipamento estar disponvel a partir do dia

01/01/2005; eo A equipe do projeto estar autorizada a utilizar as dependncias do setorde manufatura durante 24 horas por dia, todos os 7 dias da semana.

Os itens acima so os que o PMBOK cita como necessrios em um projectcharter. Porm, dependendo do projeto e das informaes disponveis, o Project Charter

pode conter:

Ligaes com outros projetos; Riscos iniciais identificados; Necessidade inicial de recursos fsicos (pessoas, equipamentos, materiais

etc.); Estrutura da equipe; Relatrios de acompanhamento que devem ser enviados ao patrocinador; Responsabilidades do Cliente; e Responsabilidades dos gerentes funcionais.

OProject Charterdeve ser emitido (assinado) por um gerente externo ao projetoe com um nvel na hierarquia da organizao adequado s necessidades do projeto. Essenvel de hierarquia que fornecer ao gerente de projeto autoridade adequada para que

possa empregar os recursos organizacionais s atividades do projeto. Pode ser umdiretor executivo ou at mesmo um vice-presidente, dependendo da amplitude erecursos envolvidos no projeto.

comum que o gerente de projeto, a ser designado, participe da elaborao

(confeco) do Project Charter, embora ele no assine. Ele deve aproveitar paranegociar os termos no documento de forma a ficar bem claro sua autoridade eresponsabilidade, o que facilitar a conduo do projeto. Se a empresa possui umescritrio de projetos (Project Office), ele encarregado, normalmente, de suaelaborao.

As empresas que prestam servios normalmente s iniciam um projeto aps aassinatura de um contrato ou documento equivalente (Carta de Inteno). Neste caso o

contrato pode servir, embora com ressalvas (uma vez que no um documento interno,no permitindo a colocao de detalhes que s interessem empresa contratada), comodocumento de autorizao do projeto. Neste caso, o ideal que o Project Chartersejaemitido tendo em anexo, ou como referncia, o contrato correspondente.

Muitas empresas no tm um documento com este nome e formato para


19/80

17

2.2.2 Definindo o Escopo do projeto

Um arquiteto, antes de fazer um projeto detalhado de como ser a casa de umcliente, elabora um esboo, estudo preliminar, normalmente denominado anteprojeto.Com este anteprojeto o arquiteto pode validar, junto ao cliente, o entendimento que eleteve dos seus desejos. Se tal entendimento (anteprojeto) for recusado pelo cliente, estesolicita novos esboos at se sentir confortvel com um deles. Somente aps essavalidao e aceitao formal por parte do cliente que o arquiteto detalha o projeto. No

gerenciamento de projetos, o processo de Definio do Escopo o responsvel pelaelaborao e validao do anteprojeto do escopo do projeto. O objetivo dessa validao no despender esforos, e portanto recursos fsicos, detalhando um escopo que podeno ter sido bem entendido. Assim sendo, o gerente de projeto, antes de sair detalhandoo escopo de um projeto, precisa fazer um estudo preliminar do que ser executadodurante o projeto. Ele precisa, junto com a sua equipe, levantar quais so os principaissubprodutos do projeto e escolher, entre as possveis alternativas de conduo do

projeto, aquela que deve ser utilizada para a entrega desses subprodutos. A escolha

dessa alternativa e dos principais subprodutos deve ser validada com os principaisinteressados (stakeholders).

A Definio do escopo portanto o processo de elaborar e documentar aestratgia para desenvolvimento do trabalho (escopo) que ir gerar o produto do projeto.Consiste em desenvolver uma declarao escrita do escopo, incluindo os critrios

VOC PODE CONGELAR O

ESCOPO DE UM PROJETO, MASNO AS EXPECTATIVAS DOCLIENTE


20/80

18novas tecnologias, de forma a obter vantagens competitivas na execuo do projeto e /

ou no produto que ser gerado. Algumas vezes esse esforo consome tantos recursosque necessrio prever no escopo do projeto uma fase especfica para essa pesquisa.

Identificao das alternativas

Quanto maior a complexidade do produto, maior ser o leque de alternativaspara a sua gerao. Alguns exemplos de alternativas so:

Na rea de Tecnologia da Informao, para desenvolver um Sistema deInformao podemos utilizar o modelo tradicional ou o modelo em espiral;

Na rea de engenharia, um caso tpico a utilizao ou no da engenhariasimultnea. A realizao de projetos nessa rea em prazos cada vez maisreduzidos conseqncia da aplicao de processos construtivos projetados e

programados pelo sistema de Engenharia Simultnea. A Engenharia Simultnea uma metodologia de trabalho e modelo organizacional, que consiste narealizao de vrias fases de um projeto de modo colaborativo e com execuode vrias funes de engenharia simultaneamente (ou em paralelo). Por

exemplo, medida que o autor do projeto arquitetnico desenvolve o projetobsico os projetos especializados so realizados simultaneamente;

Na rea de construo naval podemos ter as alternativas de construir todo onavio em um nico estaleiro ou utilizar vrios estaleiros fazendo sees do navio

para depois ser feita a montagem final; Na rea de Telecomunicaes, as peas para a montagem de uma antena podem

vir em blocos pr-montados em algum outro local ou serem totalmentemontados no local em que a antena ser erguida;

Na rea de engenharia civil, uma ponte pode ser iniciada simultaneamente decada margem do rio ou ser construda a partir de uma das margens somente; Outro exemplo na engenharia civil, para a construo de uma casa, pode ser

utilizado o sistema de casas pr-fabricadas (em que os mdulos so construdosem uma fbrica e transportados para o local de edificao) ou ser elaborado um

projeto (design) especfico com a construo in-loco.

Existe uma variedade de tcnicas para que a equipe do projeto levante possveisalternativas de projeto. As principais so:

Brainstormingou "tempestade de idias" (os mineiros chamam esta tcnica detor de parpites): consiste em uma tcnica grupal de pensamento divergente

para produo de uma grande quantidade de idias; expondo ao mximo nossainteligncia, desbloqueando dessa forma, hbitos e atitudes inibidoras de umraciocnio criati o E istem d as ariantes para esta tcnica; a saber:


21/80

19de aguardar a sua vez; cabendo ao coordenador estimular a participao

de todos os participantes. Pensamento Lateral: criado por Edward de Bono, o conceito de pensamento

lateral consiste na gerao de novas idias e no abandono das obsoletas.Aplicado ao gerenciamento de projetos, uma tcnica para aumentar acriatividade da equipe na busca de alternativas de projeto. Ela consiste emestimular o crebro atravs da atitude de quebrar os princpios estabelecidos e

passar a encarar a realidade de um modo diferente. De Bono distingue opensamento lateral (descontnuo e destinado gerao de idias) do vertical(contnuo e orientado para as desenvolver). Enquanto o pensamento lateral didias, o vertical as desenvolve.

A Declarao do Escopo (Scope Statement)

A declarao do escopo justamente o anteprojeto do escopo de um projeto. Elafornece a documentao que servir de base para tomada de decises futuras no projetoe para confirmar ou desenvolver um entendimento comum do escopo entre as partes

envolvidas (stakeholders). Com o progresso do projeto, a declarao do escopo podenecessitar ser revisada ou refinada para refletir as mudanas aprovadas no escopo do

projeto.

A declarao do escopo pode conter, tanto diretamente ou atravs de referncia aoutros documentos, os seguintes itens:

Produto do projeto descrio do(s) produto(s) do projeto - Uma verso

preliminar da descrio do produto, que documenta as caractersticas do produtoou servio que o projeto est incumbido de criar, consta da Declarao deEscopo Preliminar. Algumas vezes, durante o processo de Definio de escopo,so obtidas informaes adicionais acerca do produto do projeto, as quais devemser acrescentadas neste documento. importante frisar que essas novasinformaes no podem alterar o produto do projeto constante do ProjectCharter. Caso seja verificada a necessidade de alterao do escopo do produto,

previsto inicialmente, uma alterao doProject Charterdeve ser negociada.

Principais entregas do projeto uma lista dos principais subprodutos(deliverables) do projeto. Por exemplo, os principais subprodutos para um

projeto de construo de uma garagem seriam: o desenho (projeto), a garagemconstruda e o paisagismo;

i i ifi i d


22/80

20subjetividade. A definio de objetivos (metas) claros para o projeto

fundamental, pois o xito do projeto depender do alcance ou no dessesobjetivos. Um objetivo claro especfico e mensurvel. Evite objetivos vagos,como, por exemplo, "Criar uma tecnologia de ltima gerao na fabricao de

bicicletas".

Critrios de aceitao de produtos. Define o processo e / ou os critrios paraque os produtos principais ou o projeto como todo sejam aceitos.

Restries e premissas (hipteses), cujos conceitos foram vistos anteriormente.

Essas restries e premissas podem ser, alm daquelas estabelecidas no ProjectCharter, as definidas durante o processo de Definio de Escopo;

Ligaes com outros projetos;Principais estratgias do projeto;Principaisstakeholders e suas influnciasCronograma bsico do projeto;Riscos iniciais identificados;

Necessidade inicial de recursos fsicos (pessoas, equipamentos, materiais etc.);Organizao inicial da equipe do projeto e seus componentes;Relatrios de acompanhamento que devem ser enviados ao patrocinador;Estimativas iniciais de custo;Responsabilidades do Cliente;Escopo no includo no projeto; eResponsabilidades dos gerentes funcionais.

A Declarao de Escopo deve ser assinada pelo Gerente do Projeto e pelosprincipais interessados (stakeholders). Consideramos como principais interessadosaqueles com envolvimento direto na alocao de recursos (patrocinador e gerentesfuncionais) e no recebimento dos principais subprodutos (cliente).


23/80

21

2.2.3 Criando a Estrutura Analtica do Projeto (EAP)

No subitem anterior vimos que a Declarao de Escopo o anteprojeto

do escopo de um projeto, sendo utilizado para a validao do entendimento do escopoantes da equipe despender esforos para o seu detalhamento. Com a Declarao deEscopo assinada, representando a anuncia dos principais stakeholders, o gerente do

projeto pode iniciar, com a sua equipe, o detalhamento do trabalho que ser executado,definindo o escopo do projeto. O processo de criao da WBS consiste na subdivisodos produtos (deliverables) principais do projeto, em componentes menores e maisgerenciveis, at que todo o escopo do projeto tenha sido identificado.

O nvel de detalhamento do escopo deve ser feito de maneira a: Definir uma base de referncia (baseline) para a medio e controle do

desempenho (a base de referncia do projeto uma fotografia do escopodefinido e autorizado, juntamente com o prazo e oramento planejados para esseescopo);

Aumentar a exatido das estimativas (quanto maior o detalhamento, maisprecisas sero as estimativas de tempo e custo); e

Facilitar a definio clara de responsabilidades (permitindo a associao do

trabalho a ser realizado com os responsveis por sua execuo).

Embora o planejamento de um projeto inicie pelo escopo, comum que oplanejamento das outras reas influenciem na definio do escopo. Abaixo, algunsexemplos:

EU SEI QUE VOC ACREDITAQUE ENTENDEU O QUE VOCPENSA QUE EU DISSE, MAS EUNO ESTOU CERTO QUE VOCCOMPREENDEU QUE O QUEVOC OUVIU NO O QUE EUQUIS DIZER (AUTOR ANNIMO)


24/80

223. rea de Custos se a equipe for realizar o gerenciamento pelo valor

agregado (EVM - Earned Value Management), uma das tcnicas doprocesso de Controle de Custos, esse trabalho de gerenciamento deve serprevisto no escopo do projeto;

4. rea de Tempo para a utilizao de um software que permita o Controledo Cronograma, pode ser necessrio acrescentar ao escopo do projeto otreinamento de integrantes da equipe na utilizao desse software;

5. rea de Qualidade para atendimento de um item do processo de Garantiada Qualidade, pode ser necessria a realizao de Auditoria da Qualidade,

sendo, por conseguinte, acrescentada ao escopo do projeto;6. rea de Recursos Humanos para o processo de Desenvolvimento da

Equipe, pode ser decidida a realizao de um evento de confraternizaopara que os membros da equipe se conheam ou um treinamento em umatecnologia especfica;

7. rea de Comunicao o Plano de Gerenciamento das Comunicaes podeconcluir ser necessria a instalao de uma estrutura de videoconferncia

interligando os principais envolvidos no projeto; e8. rea de Integrao o Plano de Projeto um dos itens de escopo oriundos

dessa rea.

A Estrutura Analtica do Projeto (EAP) ou Work BreakdownStructure (WBS)

A representao utilizada para a definio do escopo, que a sada desseprocesso, a Estrutura Analtica do Projeto (WBS), traduo para o portugus de WorkBreakdown Structure. A Estrutura Analtica do Projeto (EAP) a base para odetalhamento do trabalho do projeto. Depois de elaborada e aprovada, ela passa a ser a

base de referncia do escopo do projeto (scope baseline).

A WBS no um instrumento novo no gerenciamento de projetos, havendoregistro de sua utilizao desde o incio da dcada de 60, nos EUA, pelo Departamento

de Defesa, Indstria Aeroespacial e Indstria de Construo. Porm, algumas reascriaram a cultura de representar o escopo do projeto atravs de uma lista organizada dasatividades que seriam executadas no mesmo. Essa forma de representar o escopoenfocava o que seria feito e no o que seria entregue pelo projeto. Com o passar dotempo, cada vez mais os gerentes do projeto foram verificando que, para melhor atenderaos anseios dos Clientes / Patrocinadores era mais importante representar o escopo em


25/80

23que de melhor visualizao, o gerente do projeto necessita utilizar uma ferramenta queauxilie o desenho. Para a maioria dos gerentes que utilizam o MS/Project, que no temesse recurso, til usar uma ferramenta de apoio (add-in), como por exemplo o WBSChart Pro da Critical Tools Corporation (www.criticaltools.com). Porm, a listaidentada disponvel no MS/Project ou em qualquer editor de textos ou planilhaeletrnica, tambm pode ser utilizada para representar a WBS. O primeiro nvel daWBS chamado nvel de projeto. Abaixo podem ser vistas duas representaes para amesma WBS (no totalmente detalhada).

A WBS portanto:

Decompe o escopo do projeto, dividindo o trabalho em termos de subprodutos(deliverables); Pode apresentar o processo do ciclo de vida do projeto, em termos dos passos

apropriados para a execuo do mesmo; a base para o estabelecimento de todos os esforos (atividades) / custos a

serem despendidos para a criao dos deliverables; e D suporte atribuio de responsabilidade para a execuo e coordenao do

trabalho do projeto, ao permitir relacionar os itens da WBS aos elementos

organizacionais da empresa, atravs de uma Matriz de Responsabilidade.

Representao da WBS como uma Lista Identada

1 Projeto Computador1.1 Documentao1.2 Computador Pessoal

1.2.1 Estrutura1.2.2 Placa-Me1.2.3 Disco Rgido1.2.4 Fonte1.2.5 Montagem

1.3 Teste Sistema1.4 Sistema Operacional1.5 Gerenciamento do Projeto

Representao Grfica da WBS


26/80

24

A importncia da WBS

A importncia da WBS pode ser verificada pelo fato dela ser "entrada" paravrios processos de gerenciamento de projetos. Essa importncia fez tambm com que,tanto o Project Management Institute (PMI) como o Departamento de DefesaAmericano (DoD), editassem publicao especfica com os conceitos, caractersticas,

benefcios e passos para a criao de uma WBS. O Departamento de Defesa Americanoutiliza a WBS tanto para definir os objetivos dos seus diversos programas (Program

WBS), como para definir os itens a serem fornecidos, tais como hardware, software,dados ou servios de responsabilidade do contratado (Contract WBS).

Como criar uma WBS

A WBS pode ser criada totalmente nova ou reutilizar partes de uma outra WBSou de modelos (templates) da organizao. Ela deve conter subprodutos necessrios aogerenciamento do projeto, tais como relatrios, planos, documentao administrativa,

treinamento etc.Vale lembrar que o escopo de um projeto comea a ser definido anteriormente

elaborao da WBS, em documentos tais como Project Charter e Declarao de Escopo,que so gerados, respectivamente, nos processos de Iniciao e Planejamento deEscopo.

Enquanto em algumas reas a WBS tem freqentemente consistido de umahierarquia de 3 nveis, esse nmero no apropriado para todas as situaes. A

profundidade da WBS depende do tamanho e complexidade do projeto, e danecessidade de detalhe necessrio para o planejamento e gerenciamento.

Os elementos no decompostos em uma WBS so chamados de pacotes detrabalho (Work Packages). Os Pacotes de Trabalho devem ser descritos no Dicionrioda WBS.

Os seguintes passos podem ser usados para a elaborao de uma WBS:

Veremos abaixo uma estratgia para elaborao de uma WBS, utilizando atcnica top-down (de cima para baixo), onde usaremos, a ttulo de ilustrao, um projetode uma nova bicicleta.

1. Colocar no primeiro nvel (nvel 0) da WBS o nome do projeto.


27/80

25

2. Colocar no segundo nvel (nvel 1, tambm chamado de primeiro nvel dedecomposio) as fases que estabelecem o ciclo de vida do projeto

O segundo nvel da WBS (nvel 1)

Este o mais comum e mais fcil mtodo de desenvolver a WBS. Uma grandevantagem que a WBS resultante pode ser usada como modelo (template) para muitos

projetos. O PMBOK sugere que as fases do ciclo de vida do projeto podem ser usadascomo primeiro nvel de decomposio, com os subprodutos do projeto repetidos nosegundo nvel. Porm, no quer dizer que esta seja sempre a melhor forma de decomporinicialmente o projeto.

Alm de ter a possibilidade de ser por fases, a decomposio inicial, assim comoa decomposio em qualquer nvel, pode ser por subprodutos (ex.: decompor uma

bicicleta em suas partes principais), por sistema funcional (ex.: sistema eltrico, sistema

hidrulico, sistema mecnico...), por localizao fsica (ex.: regio nordeste, regio sul...), por Unidade Administrativa a executar (ex.: divises, departamentos ...) ou atmesmo por cliente (ex.: de acordo com a fiscalizao).

3. Acrescentar um elemento, no segundo nvel (tambm chamado de primeironvel de decomposio), para conter os deliverables (subprodutos) necessrios aogerenciamento do projeto.


28/80

26

4. Identificar os subprodutos necessrios para que seja alcanado o sucesso doprojeto em cada fase (ou outra forma de decomposio citada acima no item 2).

Nesta hora devemos consultar os documentos de alto nvel que guiam o escopodo projeto (Project Charter e Declarao de Escopo) assim como entrevistar clientes eusurios, de forma a identificarmos os subprodutos de cada fase. Caso o nmero desubprodutos no nvel filho fique muito grande (mais de 8), eles devem ser agrupados,aumentando em mais um nvel a WBS.

Em relao ao gerenciamento do projeto, devemos identificar os subprodutosque sero necessrios aos macros processos de Iniciao, Planejamento, Controle,Execuo e Encerramento do projeto. O Plano do Projeto o grande deliverable do

planejamento do projeto. trabalho do gerente do projeto definir se o plano ser maisou menos detalhado.

Para o controle do projeto, podem ser necessrios, por exemplo:

Reunies, tais como as de partida do projeto (Kick-off Meeting) e deacompanhamento (walktroughs);

Relatrios de desempenho;

Anlise EVM -Earned Value Management; e

Para o encerramento do projeto, podemos gerar:

Relatrio final do projeto;

Relatrio de Lies Aprendidas;

Comemoraes; e Apresentao do projeto completo.

5. Para cada subproduto, verificar se as estimativas de custo e tempo, assim comoa identificao de riscos, podem ser desenvolvidos neste nvel de detalhe e se


29/80

27Os elementos nos nveis mais baixos da WBS (aqueles que no foram

decompostos), so denominados pacotes de trabalho (work packages), sendo a baselgica para a definio de atividades, designao de responsabilidades, estimativa decustos e planejamento de riscos. Ateno que no necessrio que a WBS sejasimtrica, ou seja, que todos os subprodutos sejam decompostos at o mesmo nvel.

Quando um determinado elemento da WBS for ser contratado a uma empresaexterna ao projeto, ele no necessita ser decomposto na WBS em subprodutos, uma vezque incumbncia do fornecedor / prestador de servio faz-lo. Da mesma forma, no

so detalhados os elementos da WBS em que o gerente do projeto decida delegar ogerenciamento do mesmo a algum membro da equipe, transformando-o em umsubprojeto. responsabilidade do gerente desse subprojeto efetuar o detalhamento.Algumas vezes o gerente do projeto, mesmo para elementos da WBS terceirizados ousubprojetos, decide incorporar o detalhamento dos mesmos na WBS do projeto mestre.Esta deciso, de detalhar ou no, nos dois exemplos citados, depender do rigornecessrio de controle. Este rigor aumenta ou diminui em funo dos fatores custos,prazos e riscos associados.

A Figura a seguir apresenta o resultado da utilizao dos passos acima para aelaborao de uma WBS no projeto de uma nova bicicleta. Nesse exemplo, aFabricao do Prottipo ser contratada externamente e, portanto, no foi detalhada

pois o rigor necessrio foi considerado baixo.


30/80

28

_____________________________________________________________________________________Gerncia de Escopo de Projetos


31/80

29

6. Rever e refinar a WBS at que o planejamento do projeto possa ser completado

Aps seguirmos os passos acima, teremos uma primeira verso da WBS. EstaWBS ser utilizada como entrada para o planejamento de outras reas do gerenciamentodo projeto.

Aps termos uma verso da WBS em que foram levadas em considerao asnecessidades das outras reas de gerenciamento, devemos realizar uma validao daestrutura gerada. No prximo subitem temos alguns mandamentos que nos ajudamnessa validao.

Os dez mandamentos da WBS

I Cobiars a WBS do prximo

Aprender com o passado uma habilidade importante dogerente de projetos. Antes de iniciar a elaborao da WBS doseu projeto, verifique como foi estruturado o escopo de projetos semelhantes. Consulteoutros projetos da empresa, veja a literatura e converse com outros profissionais degerenciamento que atuaram em projetos que tiveram como objetivo a gerao de

produtos e servios similares.

II - Explicitars todos os subprodutos, inclusive os necessrios ao gerenciamentodo projeto

O subproduto que no estiver na WBS no faz parte do escopo do projeto.Assim, no deixe nenhum de fora. Se durante a execuo do projeto, algum membroestiver trabalhando em uma atividade que no esteja contribuindo para algumsubproduto da WBS, ele estar trabalhando fora do escopo do projeto. Se esse trabalhofor necessrio ao projeto, devem ser utilizados os procedimentos para a sua incluso noescopo, referentes ao controle de alteraes do escopo.

importante lembrar que o conceito de subproduto do projeto tambm inclui osservios (Ex.: teste, alinhamento, treinamento, instalao etc.). O importante que,tanto os produtos como os servios, sejam tangveis e verificveis. A WBS no deveconter insumos / recursos fsicos a serem utilizados na gerao dos subprodutos. Oscustos de viagens, material, pessoal e outros insumos devem ser alocados ao elementoda WBS para o qual eles contribuem Devemos verificar se os subprodutos necessrios


32/80

30Manual do Equipamento, utilize Manual do Equipamento.

IV Guardars a descrio dos pacotes de trabalho no Dicionrio da WBS

Os pacotes de trabalho devem ser claramente definidos no dicionrio da WBSpara que fique bem explcito o trabalho a ser realizado. O Dicionrio da WBS odocumento que define e / ou descreve o trabalho a ser realizado em cada pacote detrabalho da WBS.

V - Decompors at o nvel de detalhe (pacote de trabalho) que permita oplanejamento e controle do trabalho necessrio para a entrega do subproduto.

O planejamento e controle incluem: escopo (verificao e controle demudanas); tempo (definio das atividades); custo (planejamento de recursos,estimativa de custo e oramento); e risco (planejamento do risco).

VI - No decompors em demasia, de forma a que o custo / tempo de planejamentoe controle no traga o benefcio correspondente.

Planejar e controlar tem o seu custo / tempo necessrio a esse trabalho. Assim,decomponha de acordo com a sua necessidade no projeto. Como exemplo, no adiantadecompor o escopo em subprodutos que durem 1 hora para serem gerados se o controleser realizado semanalmente. Por outro lado, foi citado anteriormente que os fatoresriscos e custos associados so determinantes do rigor a ser aplicado nos controles.Desta forma, caso um projeto tenha deliverables com altos nveis de incerteza (queimplicam em altos riscos) e custos elevados, os controles necessrios demandaro uma

decomposio extremamente detalhada. Como exemplo, a WBS de um projeto deconstruo de um veculo lanador de satlites (que custa algumas centenas de milhesde dlares) ser muito mais detalhada do que a WBS da construo de uma casa pr-fabricada de 2 quartos (que custa alguns milhares de reais).

VII Honrars o pai

Cada elemento da WBS deve ser um componente do subproduto do elemento pai

ao qual est subordinado. Verifique se os elementos filhos na WBS so realmentecomponentes dos elementos pais. Por exemplo, o fato de um treinamento depender deum manual do equipamento ter sido disponibilizado no quer dizer que faa parte dotreinamento a elaborao do manual.


33/80

31

IX - No decompors em somente um subprodutoUm elemento da WBS no deve ter somente um componente (filho). De acordo

com o mandamento anterior, se um elemento tem somente um componente, ele igualao pai. Se for, porque represent-lo duas vezes? Quando isso ocorrer, verifique se, narealidade, no esqueceu de algum componente. Caso no tenha esquecido, desnecessria a representao do elemento filho.

X No repetirs o mesmo elemento como componente de mais de um subprodutoNo podemos ter um elemento como (filho) componente de mais um subproduto

(pai). Por exemplo, se para ministrarmos dois treinamentos utilizarmos a mesmaapostila, no devemos coloc-la como subproduto dos dois treinamentos a elaboraoda mesma. importante ressaltar que podemos ter elementos com o mesmo nomecompondo subprodutos diferentes, mas cada um com um significado diferente. Porexemplo, na figura a seguir, temos o mesmo nome em vrios subprodutos.

O MESMO ESCOPO DE UM PROJETO, SOB AS


34/80

32Top-down X Bottom-up

Foi apresentada acima uma estratgia para elaborao de uma WBS, utilizando atcnica top-down (de cima para baixo). Algumas equipes de gerenciamento de projetos

preferem, no entanto, trabalhar com a abordagem bottom-up (de baixo para cima).

O uso da abordagem bottom-up consiste em criar uma lista dos subprodutos(deliverables) do projeto e depois ir agrupando os mesmos at chegar no nvel 0 (nvelde projeto) da WBS. Com essa abordagem voc pode perder um grande benefcio! Voc

pode no conseguir uma viso completa do projeto, sendo possvel voc esquecer algum

subproduto.Se voc achar que voc (ou sua equipe) tenha mais facilidade, em determinado

projeto, para utilizar a abordagem bottom-up, aqui esto os passos para a construo daWBS:

1. Liste os subprodutos do projeto.

2. Agrupe os subprodutos relacionados entre si para criar um nvel acima quecontenha de dois a oito subprodutos por grupo. O nome do elemento superior,

criado em razo do agrupamento, deve sintetizar as entregas dos elementosagrupados.

3. Agrupe os elementos do nvel mais alto, criado no passo 2, criando um nvelacima, se possvel, tambm contendo de dois a oito elementos.

4. Repita o agrupamento at que voc chegue ao nvel de projeto.

5. Revise a WBS perguntando: Est faltando alguma entrega do projeto?

6. Confira a WBS utilizando os dez mandamentos citados anteriormente.

Dicionrio da Estrutura Analtica do Projeto (WBS)

o documento que define e / ou descreve o trabalho a ser realizado em cadapacote de trabalho da WBS. Um dicionrio da WBS deve incluir informaes taiscomo:

Nmero de Identificao na WBS, tambm chamado pelo PMBOK de cdigode contas (code of accounts) que pode ser usado para apropriao dos custos;

Escopo: especificao do subproduto a ser gerado; o trabalho necessrio para agerao do mesmo; critrios de aceitao do subproduto;

Tempo:durao;data prevista para incio e fim; prazo para a aceitao edependncia de outros subprodutos;C i i d i


35/80

33Para aqueles que utilizam o software Microsoft Project, uma forma de

implementao do Dicionrio da WBS utilizando as Informaes sobre a Tarefa,

que podem ser acessadas ao se clicar duas vezes sobre uma tarefa. O Dicionrio tambmpode ser implementado em um editor de textos. Um modelo de Dicionrio da WBSpode ser visto abaixo.

A especificao de um pacote de trabalho contm informaes sobre o produto aser gerado, podendo conter figuras, grficos ou textos. As especificaes podem ser doseguinte tipo:

Especificaes de Projeto (desenho): detalham as caractersticas fsicas(design), com o risco de execuo para o Contratante;

Especificaes de desempenho: especificam as caractersticas mensurveis deperformance que devem ser atingidas durante a operao do produto final, com orisco de execuo para o contratado; e

Especificaes funcionais: descrio do uso final de um item para estimular acompetio em itens comerciais ao menor custo total. um subconjunto daespecificao de desempenho, com o risco da execuo recaindo sobre o

contratado.

EXEMPLOSDEAPRESENTAODEUMDICIONRIODAWBS

Os exemplos abaixo apresentam apenas o escopo dos pacotes de trabalho (workpackages), uma vez que o objetivo atender gerncia de escopo.

EXEMPLO 1

Pacote de Trabalho Descrio3.1 Levantamento do Estadodo Acervo

As atividades referentes a este servio sero realizadas por umespecialista no tratamento de acervos documentais.

Sero realizadas uma ou mais visitas ao arquivo doCabido Metropolitano, de forma a identificar, para cada obra:

1. Se organizada em partes ou em partitura;2. Quantidade de pginas;3. Os tamanhos mximo e mnimo das pginas;4. O estado de conservao dos manuscritos; e5. Obras com necessidade de um trabalho prvio de

restaurao


36/80

34utilizado um formulrio pr-impresso, de acordo com omodelo no Anexo II. Cada obra receber um nmero, que sero seu identificador na pgina da internet e nos CD-ROMs.

EXEMPLO 2

Pacote de Trabalho Descrio3.2.1 WELCOME EVENT Evento de boas-vindas para conferencistas que chegam um dia

antes do incio da conferncia. Consistir em um coquetel

oferecido no prprio hotel do evento, para cerca de 100pessoas, com durao de 2 horas. O buffet, cardpio e bebidasdevem ser aprovados pelo Depto de Marketing.

EXEMPLO 3

Pacote de Trabalho Descrio2.3.1 Requisio de

Materiais

A requisio de materiais deve atender s normas da

CEN e da INB seguindo os rigorosos padres de controle dequalidade estipulados no documento : Guia Tcnico deQualidade de Materiais para Instalaes de Plantas

Nucleares, fornecido pelo cliente, junto ao memorial tcnicode especificaes.


37/80

35

2.2.4 Obtendo a aceitao do escopo

Ao trmino do planejamento do projeto, todos os subprodutos (deliverables) doprojeto estaro representados na Estrutura Analtica do Projeto (WBS). Com o incio daexecuo do projeto, o trabalho realizado pela equipe comea a gerar os subprodutos.Por exemplo, em um projeto de construo de uma casa, um dos subprodutos oanteprojeto (esboo preliminar). Aps a prontificao desse documento, o arquitetonecessita que o cliente o aprove antes de continuar no detalhamento do projeto (design).

Este processo, que faz parte do grupo de processos de Controle, deve ocorrera cada entrega ou, pelo menos, ao final de cada fase do ciclo de vida do projeto, a fim

de revisar os deliverables entregues e os resultados do trabalho, garantindo que otrabalho que deveria ser realizado foi realmente executado.

Enquanto o processo de Controle de Qualidade (um dos processos deGerenciamento da Qualidade do Projeto) est preocupado com a exatido doresultado do trabalho, a Verificao de Escopo est querendo a aceitao domesmo.

Embora este processo seja bem simples em termos de objetivos, ele tem papelpreponderante para a continuidade do projeto no caminho certo. O Dicionrio da WBStem papel importante neste processo, uma vez que os critrios de aceitao dossubprodutos devem estar l explicitados. Se esses critrios no estiverem claros, ser

A ACEITAO FORMAL DO ESCOPO FATOR FUNDAMENTAL PARA OCUMPRIMENTO DO PLANEJAMENTODO PROJETO


38/80

36deve estar completa, para que se possa ento, obter a aceitao formal por parte dos

stakeholders.

Aceitao Formal

O que se pretende obter a aprovao formal do escopo do projeto por parte deseus interessados (stakeholders). A formalidade da aceitao tem dois objetivos

principais:

9 Cuidado na aceitao: a formalidade faz com que oresponsvel pela aceitao (principalmente o cliente interno que no estdesembolsando recursos financeiros como contrapartida ao recebimento dosdeliverables) tenha um maior cuidado na validao dos produtos e servios que estosendo entregues pelo projeto. Diz um velho ditado de Minas Gerais: Se falado bom,escrito melhor ainda. Lembre-se sempre disto pois, quando tudo est indo bem,

podemos ser levados a relaxarmos nossos cuidados. Mas quando situaes crticas e / ouextremadas ocorrerem, uma simples assinatura (ou a ausncia dela) pode ser odiferencial entre o amadorismo e o profissionalismo; e

9 Documentao: deixar registrado quem aceitou o deliverable,permitindo a continuidade do projeto, principalmente a execuo das atividadesdependentes dessa aceitao.

Se o projeto for finalizado antes do trmino (abortado), o processo de verificaodo escopo do projeto deve determinar e documentar o nvel e a extenso do trmino.

A formalizao do aceite um processo que pode ser limitado s entregas maisimportantes do projeto. O gerente do projeto pode tomar a deciso de quais entregasdevem ser formalizadas e de que maneira. Podemos utilizar uma mensagem (e-mail) oua assinatura em uma ata de reunio para que o responsvel formalize o aceite ou utilizarum documento padronizado.


39/80

37

2.2.5 Controlando o escopo do projeto

O planejamento adequado o principal elemento para o sucesso de qualquerprojeto. Para o desenvolvimento de um plano de projeto realista, fundamental adefinio do trabalho a ser realizado (escopo), atravs da elaborao de uma EstruturaAnaltica do Projeto (WBS). Essa WBS, juntamente com o cronograma e o oramentocorrespondentes, formam a linha base (base de referncia) do projeto, em relao qual realizado o acompanhamento do projeto, permitindo a medio de desempenho.

Durante a execuo do projeto praticamente inevitvel ocorrer solicitaes de

alteraes no escopo do mesmo. Um fator crtico de sucesso para o gerenciamento doescopo a conduo estruturada do processo de solicitao de mudanas, com autilizao de um procedimento formal, previamente definido e documentado.

O processo de Controle do Escopo deve garantir que todas as mudanassolicitadas e aes corretivas recomendadas sejam controladas. O controle do escopo do

projeto tambm usado para gerenciar as mudanas no momento em que efetivamenteocorrem e integrado a outros processos de controle. Esse controle envolve

procedimentos e padres que so usados para gerenciar as alteraes, os quais devem ter

sido previstos no "Plano de Gerenciamento de Escopo".

Este plano, tambm um dos resultados do Planejamento do Projeto, descrevecomo os pedidos de alteraes do escopo sero gerenciados e como as mudanasautorizadas sero integradas ao projeto. Deve incluir uma descrio clara de como as

O ESCOPO CONGELADO EM UMPROJETO E O ABOMINVELHOMEM DAS NEVES TM ALGOEM COMUM: AMBOS SO MITOS

E DESAPARECEM QUANDOSUFICIENTE CALOR APLICADO


40/80

38 Quem pode solicitar alteraes no escopo do projeto;

De que maneira (via formulrio padro ou software) o pedido deve ser feito;

Quem ir avaliar o impacto das mesmas no projeto e, se for o caso, emprojetos que possuam interdependncia;

Quem autoriza ou no essas alteraes;

Os nveis de autorizao, de acordo com o impacto das alteraes (se for o

caso);

Freqncia de avaliao do escopo do projeto; e

Freqncia de atualizao do Plano de Gerenciamento de Escopo.

Caso uma proposta de mudana altere o escopo estabelecido no Project Charterouna Declarao de Escopo, a autorizao da mesma deve ser concedida por quem assinou

o documento correspondente.O Plano de Gerenciamento de Escopo deve ser assinado pelo Gerente do Projeto

e pelos principais stakeholders, no nvel de gerncia, que estaro envolvidos nasolicitao, avaliao ou autorizao de alteraes de escopo do projeto.

Um exemplo do Plano pode ser visto no anexo.


41/80

39

Dvidas Freqentes em relao ao controle de alteraes de escopo

1. Uma alterao de escopo pode ser solicitada tanto pelo cliente comopela equipe do projeto?

Resposta: Sim. A necessidade de uma alterao de escopo pode partir dequalquer lugar. O fundamental que seja cumprido o Plano de Gerenciamento deEscopo no que tange aos procedimentos a serem seguidos. Caso a equipe do projeto

verifique que uma mudana no escopo do projeto possa vir a beneficiarconsideravelmente o escopo do produto do cliente, ela deve, antes de elaborar umpedido de alterao, estimar os impactos da mudana, de forma a no gerarexpectativas no cliente de algo cujo custo-benefcio no seja compensador.

2. Quem autoriza as alteraes de escopo do projeto o Gerente doProjeto?

Resposta:Normalmente no, exceto quando ele recebe delegao para tal ou

em projetos decorrentes de contrato em que, dentro do oramento e prazoestabelecidos, o gerente tem alguma autonomia, desde que no modifique o escopo doproduto a ser entregue ao cliente.

3. Quem o Guru da FALTA DE CONTROLE de alteraes deescopo?

Resposta: Sempre que um usurio ou cliente quer burlar o controle dealteraes do escopo, o JAQUES invocado. Os pedidos so do tipo:

- J QUE voc est terminando a construo da garagem, no d para fazeruma puxadinha e construir um quartinho para ferramentas sem cobrar nenhumadicional?

- J QUE voc est mexendo nesse mdulo do sistema, ser que nopoderia fazer um programinha para acrescentar mais uma opo no menu?

- J QUE est voc est criando o banco de dados do sistema, no poderia

colocar mais um campinho nesse arquivo?

4. Quem o Guru do CONTROLE de alteraes de escopo?

Resposta: Sempre que algum usurio vier com um dos pedidos citados acimana pergunta 6, a equipe do projeto deve invocar o grande Guru NO, respondendo: -


42/80

40

3 - MATERIAL COMPLEMENTAR

3.1 Estudo de Caso

Projeto Correspondncia Eletrnica nos Correios

S.A.A Presidncia dos Correios vislumbrou a possibilidade da Empresa apresentar

aos seus clientes um novo servio, que foi denominado de "CorrespondnciaEletrnica". Esse servio consistiria em receber documentos (contas, cartas, faturas,telegramas, propagandas etc.) dos clientes em meio magntico (e-mail, site dos Correiosna Internet ou EDI Electronic Data Interchange) para que estes fossem transmitidoseletronicamente para as agncias mais prximas dos destinatrios, onde seriamimpressos e entregues aos mesmos, com maior rapidez e segurana, reduzindo tambm

o custo para os nossos clientes. Os documentos recebidos nas agncias no poderiam serrepassados para o destinatrio final por meio eletrnico, sendo de responsabilidade daagncia a impresso.

Aps ter sido proposto e aprovado pelo Conselho de Administrao paraincluso no Plano Estratgico da empresa, o Presidente determinou ao DiretorExecutivo que desenvolvesse um projeto que propiciasse aos Correios ter esse serviodisponvel em seis meses, utilizando at R$ 10.000.000,00 (dez milhes de reais) do

oramento do corrente ano. Determinou ainda que fizesse parte do projeto o estudo deviabilidade correspondente, em que o investimento tivesse o retorno financeiro(payback period) em at 5 anos.

Elaborao dos documentos

O Diretor Executivo da Empresa, aps a determinao do Presidente dedesenvolver o projeto, precisa emitir uma autorizao para incio do mesmo onde fiqueclaro: o alinhamento do projeto com o plano estratgico da empresa, o que deve ser

produzido e a designao de um gerente para a conduo do empreendimento. Almdisso, deve haver uma designao de autoridade e responsabilidade para esse gerente e oestabelecimento de premissas (hipteses) e restries O Diretor Executivo assinaria


43/80

41

Empresa Correios S.A

Nome do Projeto: Correspondncia Eletrnica nos CorreiosTermo de Abertura do Projeto

Elaborado por: Carlos Magno da S. Xavier Data: 08/08/2004

Aprovado por: Diretor Executivo Verso: 01

1.1 Justificativa do projeto (necessidades do negcio)

Com a crescente evoluo da Tecnologia da Informao (e-mail, chat, vdeo

conferncia etc.), associada s Telecomunicaes (internet, voz sobre IP, telefoniacelular etc.), vem diminuindo, ano a ano, o volume de documentos transportados pelosCorreios. Para que a empresa acompanhe e se valha dessa evoluo tecnolgica, necessrio buscar alternativas de servios aos seus clientes. Desta forma, o servio de"Correspondncia Eletrnica" se posiciona como estratgico para a empresa, tendo sidoaprovado pelo Conselho de Administrao.

1.2 Descrio do produto do projeto

O projeto deve prover uma soluo que permita o recebimento de documentos(contas, cartas, faturas, telegramas, propagandas etc.) dos clientes em meio magntico(e-mail,site dos Correios na Internet ou EDI ElectronicData Interchange) para queestes sejam transmitidos eletronicamente para as agncias mais prximas dosdestinatrios, onde sejam impressos e entregues aos mesmos, com maior rapidez esegurana, reduzindo tambm o custo para os clientes.

1.3 Designao do Gerente do Projeto

O Sr. Luiz Fernando Xavier ser o gerente deste projeto, tendo autoridade parautilizar os recursos financeiros da empresa, conforme limitao do oramento do projetoe fluxo de caixa da empresa. Est autorizado tambm a recrutar pessoal dosdepartamentos da Agncia Central e da Diretoria de Tecnologia da Informao. No casode necessidade de correspondncia oficial com rgos do Governo Federal, Estadual ouMunicipal, a Assessoria de Comunicaes deve ser consultada.

1.4 Premissas (hipteses) e restries para o projeto

Premissas (hipteses) Restries Nos prximos seis meses ser A correspondncia eletrnica deve estar


44/80

421.5 Ligaes com outros projetos

Este projeto tem forte ligao com o projeto de Ampliao da Infra-estrutura daRede de Computadores dos Correios.

1.6 Acompanhamento do projeto

O gerente do Projeto deve criar, na Intranet da empresa, um ambiente quecontenha as informaes necessrias para o acompanhamento do projeto pelos

principais envolvidos.

Sero realizadas reunies quinzenais, a nvel executivo, de acompanhamento doprojeto. Nessas reunies deve ser apresentado um relato do desempenho do projeto,contendo o realizado at o momento, comparao de tempo e custo em relao ao

planejado e uma projeo atualizada para o trmino do projeto.

Rio de Janeiro, RJ, em 08 de agosto de 2004.

______________________________________ASSINATURA DO DIRETOR EXECUTIVO

Prximo passo:

Com a emisso do Project Charter, o Gerente do Projeto tem condies deiniciar o seu planejamento. Durante o processo de Definio do Escopo, o gerente

verifica qual seria a melhor estratgia para executar o projeto e quais seriam osresultados principais (deliverables) do mesmo, assim como os objetivos a seremalcanados. O documento que formaliza esse planejamento a Declarao de Escopo,que deve ser assinada pelo gerente do projeto e pelos principais interessados,representando a concordncia dos mesmos com esse planejamento do escopo.

O Gerente do Projeto geraria ento a Declarao de Escopo a seguir.


45/80

43


Nome do Projeto: Correspondncia Eletrnica nos CorreiosDeclarao do escopo do projeto (Scope Statement)


Aprovado por: Diretor ExecutivoDiretor de TIDiretor de MarketingGerente do Projeto

Verso: 01

1.1 Justificativa do projeto (necessidades do negcio)

Com a crescente evoluo da Tecnologia da Informao (e-mail, chat, vdeoconferncia etc.), associada s Telecomunicaes (internet, voz sobre IP, telefoniacelular etc.), vem diminuindo, ano a ano, o volume de documentos transportados pelosCorreios. Para que a empresa acompanhe e se valha dessa evoluo tecnolgica, necessrio buscar alternativas de servios aos seus clientes. Desta forma, o servio de"Correspondncia Eletrnica" se posiciona como estratgico para a empresa, tendo sido

aprovado pelo Conselho de Administrao.

1.2 Produto do Projeto

O projeto deve prover uma soluo que permita o recebimento de documentos(contas, cartas, faturas, telegramas, propagandas etc.) dos clientes em meio magntico(e-mail,site dos Correios na Internet ou EDI ElectronicData Interchange) para queestes sejam transmitidos eletronicamente para as agncias mais prximas dosdestinatrios, onde sejam impressos e entregues aos mesmos, com maior rapidez esegurana, reduzindo tambm o custo para os clientes.

Faz parte do escopo do projeto o estudo de viabilidade correspondente, em quegaranta que o investimento tenha o retorno financeiro correspondente (payback period)em at 5 anos. Devem ser levantados os documentos envolvidos, possveis clientes,volumes de documentos, arquitetura de TI disponvel e requisitos legais. A tecnologiautilizada deve ser de ponta, garantindo a integridade, autenticidade e segurana dascorrespondncias. As correspondncias para cidades com menos de 10.000 habitantes

devem ser impressas na cidade mais prxima com mais de 10.000 habitantes. Osdocumentos recebidos nas agncias no podem ser repassados para o destinatrio final

por meio eletrnico, sendo de responsabilidade da agncia a impresso.

1.3 Estratgias de conduo do projeto


46/80

44das sugestes resultantes do piloto, ser realizada a implantao nas demaisunidades.

d) O marketing ser contratado externamente, devendo o planejamento do mesmoser aprovado junto com a homologao da soluo.

e) O projeto, depois de implantado, ser acompanhado pela equipe do projeto porquatro meses, ao final do qual ser emitido um relatrio do desempenho dasoluo.

f) No incio da operao estaro utilizando o novo servio, pelo menos os dezmaiores clientes dos Correios e, prontas para impresso de documentos 50% dasAgncias Postais.

1.4 Lista de deliverables principais por fases

Fases DeliverablesEstudo de Viabilidade Estudo de viabilidadeDefinio Especificao de equipamentos e softwaresContratao ContratosImplementao Customizao de softwares

Manual de ProcedimentosPlano de MarketingPlano de ContingnciaHomologao da soluo

Implantao Marketing do produtoCall CenterImplantao PilotoImplantao nas demais unidades

Teste IntegradoRelatrio inicial do desempenho da soluoimplantada

Fechamento Relatrio do Projeto

1.5 Excluses de escopo

No faz parte do escopo deste projeto:

Fazer a contratao e treinamento de pessoal para a operao do Call Center; e Levantar a necessidade de alteraes da infra-estrutura de TI da empresa para

suportar este projeto, o que responsabilidade do projeto de Ampliao daInfra-estrutura da Rede de Computadores dos Correios.


47/80

45 Os Correios e os seus 10 maiores clientes tero suas assinaturas digitais

criadas e certificadas at 28/11/2004; O Conselho de Administrao analisar em 5 dias o estudo de viabilidade,

dando nesse prazo a resposta para continuidade ou no do projeto; Ser disponibilizado para a equipe do projeto, em regime de dedicao

exclusiva, um profissional das seguintes reas: marketing; logstica; edistribuio; e

Sero utilizadas as Agncias da cidade de Niteri como implantao piloto,de forma a validar a implementao da soluo.

1.7 Restries do projeto

A correspondncia eletrnica deve estar Implantada em 6 meses, utilizando atR$ 10.000.000,00 (dez milhes de reais).

1.7 Ligaes com outros projetosEste projeto tem forte ligao com o projeto de Ampliao da Infra-estrutura da

Rede de Computadores dos Correios.

1.8 Acompanhamento do projeto

Ser criado, na Intranet da empresa, um ambiente que contenha as informaesnecessrias para o acompanhamento do projeto pelos principais envolvidos. OsDiretores de TI e de Marketing informaro, at 05 de setembro de 2004 a relao dosusurios autorizados a acessar esse ambiente.

Sero realizadas reunies quinzenais, a nvel executivo, de acompanhamento doprojeto. Nessas reunies ser apresentado um relato do desempenho do projeto,contendo o realizado at o momento, comparao de tempo e custo em relao ao

planejado e uma projeo atualizada para o trmino do projeto. Ser utilizada a tcnicade Anlise do Valor do Trabalho Realizado (EVM Earned Value Management) para amedio do progresso do projeto.

Sero realizadas reunies semanais, com a equipe, para acompanhamento doprojeto.

1.9 Equipe de planejamento do projeto

A equipe de planejamento do projeto constituda por: Gerente do Projeto: Sr. Luiz Fernando da Silva Xavier;


48/80

46

Rio de Janeiro, RJ, em 28 de agosto de 2004.

__________________________________ASSINATURA DO GERENTE DO PROJETO

_________________________________ASSINATURA DO DIRETOR EXECUTIVO

________________________________ASSINATURA DO DIRETOR DE TI

_____________________________________ASSINATURA DO DIRETOR DE MARKETING

Comentrio:

A justificativa do projeto e a descrio do produto da declarao de escopo,foram copiadas do Project Charter. A declarao de escopo no pode alterar o que foi

estabelecido naquele documento, podendo, no entanto, detalhar mais o seu contedo. Aspremissas constantes do Project Charter foram validadas e acrescidas de mais umadurante o processo de Planejamento de Escopo. As restries de tempo e custo,estabelecidas no Project Charter, passaram a fazer parte dos objetivos na Declarao deEscopo. Foi acrescentado tambm um objetivo restringindo a implantao do novoservio, quando do incio da operao do sistema, aos dez maiores clientes dos Correiose a 50% das Agncias Postais.

Prximo passo:

Aps os principais interessados terem assinado a Declarao de Escopo, oescopo deve ento ser detalhado atravs da elaborao da WBS, que definir a base dereferncia para o escopo.


49/80

47


Nome do Projeto: Correspondncia Eletrnica nos CorreiosEstrutura Analtica do Projeto (Work Breakdown Structure)


Aprovado por: Diretor de TIDiretor de MarketingGerente do Projeto

Verso: 01

1. Projeto "Correspondncia Eletrnica nos Correios"

1.1.Gerenciamento do projeto1.1.1. Plano do Projeto1.1.1.1. Escopo

1.1.1.1.1. Declarao de Escopo1.1.1.1.2. WBS1.1.1.1.3. Dicionrio da WBS

1.1.1.2. Cronograma1.1.1.3. Oramento

1.1.1.4. Matriz de Atribuio de Responsabilidades1.1.1.5. Plano de Gerenciamento de Recursos Humanos1.1.1.6. Plano de Resposta a Riscos1.1.1.7. Plano de Gerenciamento da Qualidade1.1.1.8. Plano de Gerenciamento das Comunicaes1.1.1.9. Plano de Gerenciamento das Aquisies1.1.1.10. Plano Integrado de Mudanas1.1.1.11. Apresentao do Plano do Projeto

1.1.2. Controle1.1.2.1.Reunies1.1.2.2.Relatrios1.1.2.3. Site na Intranet

1.2.Estudo de Viabilidade1.2.1. Estudo viabilidade

1.2.1.1. Viabilidade Tcnica1.2.1.1.1. Relatrio opes de tecnologia1.2.1.1.2. Relatrio fornecedores potenciais

1.2.1.2.Viabilidade Econmica1.2.1.2.1. Relatrio da pesquisa com os clientes1.2.1.2.2. Medida dos impactos nos negcios1.2.1.2.3. Restries legais1.2.1.2.4. Definio Agncias centralizadoras


50/80

481.4.1. Solicitao de Propostas1.4.2. Relao de fornecedores selecionados

1.4.3. Negociao contratos1.4.4. Contratos1.5.Implementao da soluo

1.5.1. Instalao hardware e software para desenvolvimento1.5.2. Customizao de softwares1.5.3. Testes1.5.4. Manual de Procedimentos1.5.5. Preparao Call Center

1.5.6. Plano de Contingncia1.5.7. Plano de Marketing1.5.8. Homologao da soluo

1.6.Implantao da soluo1.6.1. Marketing do produto1.6.2. Call Center1.6.3. Implantao Piloto

1.6.3.1.Instalao hardware e software para operao1.6.3.2.Treinamento1.6.3.3. Acompanhamento da operao Piloto1.6.3.4.Relatrio do Piloto

1.6.4. Atualizao da soluo em funo do piloto1.6.5. Implantao demais unidades (subprojeto)1.6.6. Relatrio inicial do desempenho da soluo implantada

1.7.Fechamento1.7.1. Encerramento de contratos1.7.2. Relatrio de lies aprendidas

1.7.3. Relatrio do Projeto

Aprovao:

Rio de Janeiro, RJ, em 10 de setembro de 2004.

_____________________________________ASSINATURA DO GERENTE DO PROJETO

_______________________________ASSINATURA DO DIRETOR DE TI


51/80

49Comentrio:

A WBS foi elaborada a partir das fases e dos deliverables principais listados nadeclarao de escopo. O detalhamento da WBS depender do tamanho e complexidadedo projeto, e da necessidade de detalhe para o planejamento e controle do projeto.

Durante o planejamento do projeto deve ser emitido o Plano de Gerenciamento deEscopo. Abaixo segue um exemplo de Plano para o caso acima.


Nome do Projeto: Correspondncia Eletrnica nos Correios

Plano de Gerenciamento do Escopo


Aprovado por: Diretor de TIDiretor de MarketingGerente do Projeto

Verso: 01

I INTRODUO

II O GERENCIAMENTO DE ALTERAES DE ESCOPO

O trabalho a ser realizado neste projeto (baseline de escopo) est documentadona Estrutura Analtica do Trabalho (WBS) e em seu Dicionrio. Nenhum trabalho deveser realizado pela equipe do projeto que no esteja definido nesta baseline. Essa WBSfoi elaborada tendo como base a Declarao de Escopo.

Este plano apresenta os procedimentos que sero usados para gerenciar asalteraes no escopo do projeto, ou seja, como as mudanas do escopo seroidentificadas, classificadas e, se autorizadas, integradas ao projeto. O objetivo garantirque sejam coletadas todas as informaes relacionadas mudana solicitada, alm deque seja realizada, para cada alterao proposta, uma avaliao dos impactos no projeto(custo, prazo, qualidade e risco), assim como em seus objetivos. As alteraes propostasde escopo devem ter suporte nas metas fundamentais de negcio da empresa, em funodas quais o projeto foi autorizado.

II.1 - PROCEDIMENTOS

Quando alguma necessidade de mudana de escopo for identificada, deve sergerada uma Solicitao de Mudana de Escopo (SME). S podem emitir solicitaes demudanas os Chefes de Departamento. Esta solicitao ser analisada pelo gerente do

50


52/80

50Empresa Correios S.A

Solicitao de Mudana de Escopo n ....

Projeto:Solicitado por: Ramal:Descrio da mudana solicitada:

Justificativa:

Data: Nome: Assinatura:PARECER DO GERENTE DO PROJETO

Impactos identificados:No cronograma -No custo -Na qualidade -Em outros projetos -

Data: Nome: Assinatura :PARECER DO DIRETOR EXECUTIVO

Aprovao ( ) Rejeio ( )

Observaes:

Data: Assinatura:

II.2 - SISTEMA DE MONITORAMENTO (RASTREAMENTO)

Para manter o acompanhamento de quais mudanas foram propostas, aprovadase implementadas, ser utilizado o Software de Gerenciamento de Mudanas de Escopo

(SGME), que pode ser acessado atravs da intranet da empresa. O solicitante responsvel pela digitao da solicitao no sistema, o qual gera um nmero para amesma. O software implementa o workflow da SME, com os envolvidos recebendo e-mail quando necessitarem atuar no processo ou receber atualizao do status dasolicitao. Em caso de indisponibilidade do sistema ou urgncia na aprovao damudana, poder ser preenchido o formulrio em papel, que pode ser conseguido junto equipe do projeto.

II.3 - ATUALIZAO DA BASE DE REFERNCIA DO ESCOPO

Caso a mudana de escopo seja autorizada, deve ser produzido um conjunto decorrees nos documentos de escopo ou uma nova verso destes documentos.

Aprovao do Plano:

51


53/80

51

3.2 EXERCCIO

Tendo em vista o texto abaixo, elaborar o Termo de aberturacorrespondente:

No momento atual, em que vrias organizaes esto passando por

mudanas estruturais em direo a uma orientao por projetos, torna-semais evidente a necessidade de se estabelecer metodologias de gesto queconduzam ao sucesso ou que, pelo menos, aumentem a probabilidade deatingir o sucesso em seus projetos. Para tal, torna-se necessria acapacitao de profissionais das Organizaes em ferramentas e tcnicaspara o gerenciamento desses projetos.

Pesquisa realizada em 2003 pelo Meta Group. com executivos de TI,mostra que as empresas que vm adotando o gerenciamento efetivo deportflio tm registrado uma melhora contnua na eficincia de seusprojetos, reduzindo seus custos em at 30%.

A empresa Beware Consultoria Empresarial Ltda possui um portflio

de projetos de cerca de R$ 15 milhes / ano. Com o objetivo de obter umareduo de, no mnimo, 10% nos custos dos projetos no prximo ano, tendocomo foco principal a otimizao dos recursos fsicos e financeiros daempresa, por meio de um melhor gerenciamento dos projetos, o DiretorExecutivo da empresa determinou a realizao de um treinamento emgerenciamento de projetos (GP), a ser realizado nas instalaes da empresa,tendo como pblico alvo profissionais que trabalham em projetos de

Tecnologia da Informao e de Engenharia. Esse treinamento deve tercomo base a metodologia methodware de gerenciamento de projetos, cujacontratao estar concluda pelo Departamento financeiro em 10 dias.

O t i t b t l di t ti f h d l

52


54/80

52

Exerccio

No texto da pgina anterior, identifique:

Documents

Apostila Gerencia Escopo Magno FGV