Escolar Documentos
Profissional Documentos
Cultura Documentos
GERNCIA DE ESCOPO EM
PROJETOS
Carlos Magno da Silva Xavier
(M.Sc., PMP)
magno@fgvmail.br
Realizao
Fundao Getulio Vargas
FGV Management
ii
Sumrio
1. PROGRAMA DA DISCIPLINA
1.1 EMENTA
1.2 CARGA HORRIA TOTAL
1.3 OBJETIVOS
1.4 CONTEDO PROGRAMTICO
1.5 METODOLOGIA
1.6 CRITRIOS DE AVALIAO
1.7 BIBLIOGRAFIA RECOMENDADA
CURRICULUM RESUMIDO DO PROFESSOR
1
1
1
1
2
2
2
2
2.1 INTRODUO
2.2 GERENCIAMENTO DO ESCOPO DO PROJETO
2.2.1 INICIANDO O PROJETO
2.2.2 DEFININDO O ESCOPO DO PROJETO
2.3.3 CRIANDO A ESTRUTURA ANALTICA DO PROJETO
2.3.4 OBTENDO A ACEITAO DO ESCOPO
2.3.5 CONTROLANDO O ESCOPO DO PROJETO
3
7
9
17
21
35
37
3 MATERIAL COMPLEMENTAR
40
ii
1. Programa da disciplina
1.1 Ementa
Iniciao. Project Charter. Planejamento de escopo. Deliverables. Definio de
objetivos. WBS - Work Breakdown Structure. Detalhamento do escopo.
Verificao e acompanhamento do escopo. Controle de mudanas no escopo.
1.3 Objetivos
_____________________________________________________________________________________
Gerncia de Escopo de Projetos
1.5 Metodologia
Exposio da teoria entremeada por debates, estudos de caso, exerccios e relatos
da vivncia profissional.
_____________________________________________________________________________________
Gerncia de Escopo de Projetos
4
respostas 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. O
assunto to importante que vrias organizaes se especializaram na gerncia de
projetos. O novo ambiente de negcios, caracterizado por uma grande pulverizao de
equipes, cada vez mais distantes geograficamente, apresenta um grande desafio
gerencial 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 de
projetos, com objetivos claros, recursos materiais / financeiros limitados, e princpio,
meio e fim bem definidos. A resposta a esse desafio passa pelo desenvolvimento de
Tcnicas, Metodologias, Tecnologias e as Best Practices de Gerenciamento de Projetos
(Project Management).
Uma metodologia formal de gerenciamento de projeto habilita a empresa a
maximizar a consistncia, eficincia, qualidade e produtividade em projetos. Segundo o
Standish Group, em seu relatrio Extreme CHAOS 2001, graas ao uso de melhores
mtodos de gerenciamento, o percentual de sucesso em projetos nos EUA cresceu de
34% em 1994 para 55% em 2000, o que pode ser verificado no grfico da figura abaixo.
Projetos que
obtiveram
sucesso
120000
100000
Projetos que
fracassaram
80000
60000
40000
Total de
Projetos
20000
0
1994
2000
_____________________________________________________________________________________
Gerncia de Escopo de Projetos
5
O PMI - Project Management Institute - hoje a organizao lder em
Gerenciamento de Projetos em todo o mundo. Criado nos EUA (Pensilvnia) em 1969,
uma instituio sem fins lucrativos dedicada ao avano do estado-da-arte em
gerenciamento de projetos e seu principal compromisso "promover o profissionalismo
e a tica em gesto de projetos". Atualmente, o PMI est representado no Brasil pelas
seguintes sees regionais (Chapters): So Paulo, Rio de Janeiro, Distrito Federal, Rio
Grande 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 no site 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 obtidos
em gerenciamento de projetos, desde os seminrios organizados na dcada de 60 pelo
Departamento de Defesa (DoD), NASA e outras organizaes governamentais
americanas. O PMBOK sugere quais processos devem ser executados, durante o
gerenciamento 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 ser
feito, mas no o como implementar esses processos.
RH
Tempo
Custo
Aquisies
INTEGRAO
Comunicao
Escopo
Qualidade
Riscos
_____________________________________________________________________________________
Gerncia de Escopo de Projetos
6
6.
7.
8.
9.
10.
Esta disciplina pretende apresentar aos alunos como deve ser definido e
controlado o escopo em um projeto.
_____________________________________________________________________________________
Gerncia de Escopo de Projetos
_____________________________________________________________________________________
Gerncia de Escopo de Projetos
8
importante neste momento diferenciarmos Escopo do produto de Escopo do
Projeto. Enquanto o primeiro est relacionado ao conjunto de caractersticas e funes
que o produto final deve possuir, o segundo est relacionado ao trabalho que deve ser
realizado para que seja entregue o produto final do projeto, com as caractersticas e
funes definidas para o mesmo. O trabalho do projeto consiste na gerao e entrega de
produtos e servios. Enquanto o escopo do produto representado em documentos
como requisitos, especificaes, desenhos etc., o escopo do projeto representado na
Estrutura 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 do
projeto (representado na WBS) consiste no conjunto de subprodutos (produtos e
servios) que devem ser gerados para que o sistema de informao seja entregue. A
WBS conter, alm do prprio sistema que ser desenvolvido, os subprodutos
necessrios ao gerenciamento do projeto (plano do projeto, relatrios etc.), documentos
do sistema, testes, treinamento de usurios, podendo incluir a montagem do ambiente de
desenvolvimento (hardware e software), treinamento do pessoal de desenvolvimento
etc. A figura abaixo compara o escopo do produto com o escopo do projeto.
Escopo do Produto
Escopo do Projeto
X
As caractersticas ou funes
que devem ser includas no
produto ou servio
O conjunto de produtos e
servios (deliverables) que
devem ser gerados pelo projeto
REQUISITOS
/
ESPECIFICAES
WBS
_____________________________________________________________________________________
Gerncia de Escopo de Projetos
_____________________________________________________________________________________
Gerncia de Escopo de Projetos
10
o Principais Marcos (pontos de controle do projeto).
Exemplo 2: A empresa, no processo de autorizao de projetos realiza as
seguintes 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 do
projeto, 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; e
o Priorizao do projeto, com a designao do sponsor (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. Caso
faa parte, antes de comear o processo de elaborao de uma proposta, estimase o esforo para elabor-la, ou seja, o departamento tcnico especialista na
demanda faz a estimativa. Baseado nessa estimativa, a rea de vendas estima o
custo desse esforo. Este custo apresentado alta administrao para verificar
se vivel ou no tratar essa demanda. Se for vivel, autorizada a elaborao
da proposta. A proposta deve ser feita, em conjunto, pelas reas tcnica e
comercial. 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 seus
clientes, o primeiro passo a apresentao da proposta, com a estrutura,
arquitetura e prazo, para um comit chamado de CRP (Comit Revisor de
Projetos). Nesse Comit so discutidas, com todos os responsveis por reas de
Tecnologia da Informao e Infra-estrutura de todas as Business Units da
empresa, as propostas de mudanas na soluo apresentada, idias de
fornecedores, arquiteturas diferentes e realizadas trocas de experincias sobre o
mesmo tema. Aps essa reviso da proposta de projeto, elaborado um
documento chamado Planilha de Avaliao de Projeto, que levado ao CAIS
(Comit de Avaliao de Investimentos em Sistemas). Esta planilha mostra o
fluxo de caixa do projeto, indicadores BSC que sero afetados pelo sistema,
Break Event etc. Esse comit quem d o GO (autorizao) ou NO GO do
projeto.
justamente o processo de Iniciao que o responsvel por selecionar projetos
e autorizar ou no, formalmente, o incio de projetos na Empresa. Tambm parte desse
processo autorizar ou no a continuao, de um projeto j existente, para uma nova
fase. Este processo, de acordo com o PMBOK 2004, faz parte do Gerenciamento da
_____________________________________________________________________________________
Gerncia de Escopo de Projetos
11
Integrao 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 que
tenha a avaliao de sua real necessidade, estudo de visibilidade ou planejamento
preliminar. Esta fase inicial de concepo pode e deve ser considerada como um projeto
especfico, cujo objetivo demonstrar para a organizao que o projeto necessrio e
vivel.
_____________________________________________________________________________________
Gerncia de Escopo de Projetos
12
Critrios
Peso
10
Notas
Projeto A
10
Notas
Projeto B
8
Notas
Projeto C
6
Retorno financeiro
Aumento da participao no mercado
10
10
10
10
294
318
288
Desenvolvimento
de
novas 4
tecnologias
Pontuao final de cada projeto
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.
14
A gerente deste projeto ser a Sra Leila, que tem autoridade para utilizar os
recursos financeiros da empresa at o limite do oramento aprovado para este projeto,
podendo recrutar pessoal em todos os departamentos da empresa ou at admitir
funcionrios novos (quadro provisrio, com prazo determinado at o trmino do
projeto), alm de poder comprar ou alugar equipamentos e peas, desde que dentro da
programao 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 se
constituiro em restries ao projeto.
Normalmente, as restries principais so:
Tempo, tais como datas fixas, de incio e / ou de trmino, ou um prazo para a
concluso 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 em
funcionamento, sem afetar o processo de anlise de controle de qualidade, que
no ser interrompido;
Prazo de 90 dias a partir da aprovao do projeto bsico para elaborao do
Projeto 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 no
primeiro ms;
Todos os funcionrios devero ser treinados em cursos de segurana ministrados
pela prpria Usina e participar durante 10 minutos do DDS (Dialogo Dirio de
Segurana) 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 escopo
do produto do projeto. Caso seja necessria, essa limitao deve ser colocada na prpria
descrio do produto. Os exemplos abaixo no so restries ao projeto, mas sim ao
produto:
-
_____________________________________________________________________________________
Gerncia de Escopo de Projetos
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 s
necessidades do projeto; e
O novo ptio de pouso e decolagem a ser dimensionado ter, aproximadamente,
31.750,00 m2.
16
o O local de instalao do equipamento estar disponvel a partir do dia
01/01/2005; e
o A equipe do projeto estar autorizada a utilizar as dependncias do setor
de 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 project
charter. Porm, dependendo do projeto e das informaes disponveis, o Project Charter
pode conter:
O Project Charter deve ser emitido (assinado) por um gerente externo ao projeto
e com um nvel na hierarquia da organizao adequado s necessidades do projeto. Esse
nvel de hierarquia que fornecer ao gerente de projeto autoridade adequada para que
possa empregar os recursos organizacionais s atividades do projeto. Pode ser um
diretor executivo ou at mesmo um vice-presidente, dependendo da amplitude e
recursos 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 para
negociar os termos no documento de forma a ficar bem claro sua autoridade e
responsabilidade, o que facilitar a conduo do projeto. Se a empresa possui um
escritrio de projetos (Project Office), ele encarregado, normalmente, de sua
elaborao.
As empresas que prestam servios normalmente s iniciam um projeto aps a
assinatura 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), como
documento de autorizao do projeto. Neste caso, o ideal que o Project Charter seja
emitido tendo em anexo, ou como referncia, o contrato correspondente.
Muitas empresas no tm um documento com este nome e formato para
formalizar o incio de um projeto. Muitas vezes o projeto iniciado a partir de um email do Diretor divulgando, por exemplo, que a empresa assinou um contrato com um
cliente e convocando para uma reunio de partida do projeto (kick-off meeting). O
importante que exista uma divulgao formal da autorizao de incio do
empreendimento, informando, pelo menos, a justificativa do projeto, o produto a ser
gerado, assim como a responsabilidade e a autoridade do gerente do projeto.
_____________________________________________________________________________________
Gerncia de Escopo de Projetos
17
18
novas tecnologias, de forma a obter vantagens competitivas na execuo do projeto e /
ou no produto que ser gerado. Algumas vezes esse esforo consome tantos recursos
que 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 alternativas
para a sua gerao. Alguns exemplos de alternativas so:
Na rea de Tecnologia da Informao, para desenvolver um Sistema de
Informao podemos utilizar o modelo tradicional ou o modelo em espiral;
Na rea de engenharia, um caso tpico a utilizao ou no da engenharia
simultnea. A realizao de projetos nessa rea em prazos cada vez mais
reduzidos 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 na
realizao de vrias fases de um projeto de modo colaborativo e com execuo
de vrias funes de engenharia simultaneamente (ou em paralelo). Por
exemplo, medida que o autor do projeto arquitetnico desenvolve o projeto
bsico os projetos especializados so realizados simultaneamente;
Na rea de construo naval podemos ter as alternativas de construir todo o
navio 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 totalmente
montados no local em que a antena ser erguida;
Na rea de engenharia civil, uma ponte pode ser iniciada simultaneamente de
cada 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 construdos
em 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 possveis
alternativas de projeto. As principais so:
Brainstorming ou "tempestade de idias" (os mineiros chamam esta tcnica de
tor de parpites): consiste em uma tcnica grupal de pensamento divergente
para produo de uma grande quantidade de idias; expondo ao mximo nossa
inteligncia, desbloqueando dessa forma, hbitos e atitudes inibidoras de um
raciocnio criativo. Existem duas variantes para esta tcnica; a saber:
o Brainstorming Estruturado - aqui, as pessoas se manifestam segundo
uma ordem preestabelecida. Dessa forma, todos tm oportunidades
iguais para se manifestar e os mais calados so estimulados a participar
mais; e
o Brainstorming no estruturado - nesta tcnica, as pessoas podem
expressar suas idias medida que elas vo ocorrendo, sem necessidade
_____________________________________________________________________________________
Gerncia de Escopo de Projetos
19
de 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 a
criatividade da equipe na busca de alternativas de projeto. Ela consiste em
estimular o crebro atravs da atitude de quebrar os princpios estabelecidos e
passar a encarar a realidade de um modo diferente. De Bono distingue o
pensamento lateral (descontnuo e destinado gerao de idias) do vertical
(contnuo e orientado para as desenvolver). Enquanto o pensamento lateral d
idias, o vertical as desenvolve.
20
subjetividade. A definio de objetivos (metas) claros para o projeto
fundamental, pois o xito do projeto depender do alcance ou no desses
objetivos. 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 para
que 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 Project
Charter, as definidas durante o processo de Definio de Escopo;
Ligaes com outros projetos;
Principais estratgias do projeto;
Principais stakeholders e suas influncias
Cronograma 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; e
Responsabilidades dos gerentes funcionais.
A Declarao de Escopo deve ser assinada pelo Gerente do Projeto e pelos
principais interessados (stakeholders). Consideramos como principais interessados
aqueles com envolvimento direto na alocao de recursos (patrocinador e gerentes
funcionais) e no recebimento dos principais subprodutos (cliente).
_____________________________________________________________________________________
Gerncia de Escopo de Projetos
21
2.
_____________________________________________________________________________________
Gerncia de Escopo de Projetos
3.
22
rea de Custos se a equipe for realizar o gerenciamento pelo valor
agregado (EVM - Earned Value Management), uma das tcnicas do
processo de Controle de Custos, esse trabalho de gerenciamento deve ser
previsto no escopo do projeto;
4.
5.
6.
7.
8.
23
que de melhor visualizao, o gerente do projeto necessita utilizar uma ferramenta que
auxilie o desenho. Para a maioria dos gerentes que utilizam o MS/Project, que no tem
esse recurso, til usar uma ferramenta de apoio (add-in), como por exemplo o WBS
Chart Pro da Critical Tools Corporation (www.criticaltools.com). Porm, a lista
identada disponvel no MS/Project ou em qualquer editor de textos ou planilha
eletrnica, tambm pode ser utilizada para representar a WBS. O primeiro nvel da
WBS chamado nvel de projeto. Abaixo podem ser vistas duas representaes para a
mesma 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
Projeto Computador
1.1
Documentao
1.2
Computador Pessoal
1.2.1 Estrutura
1.2.2 Placa-Me
1.2.3 Disco Rgido
1.2.4 Fonte
1.2.5 Montagem
1.3
Teste Sistema
1.4
Sistema Operacional
1.5
Gerenciamento do Projeto
Representao Grfica da WBS
_____________________________________________________________________________________
Gerncia de Escopo de Projetos
24
A importncia da WBS
A importncia da WBS pode ser verificada pelo fato dela ser "entrada" para
vrios processos de gerenciamento de projetos. Essa importncia fez tambm com que,
tanto o Project Management Institute (PMI) como o Departamento de Defesa
Americano (DoD), editassem publicao especfica com os conceitos, caractersticas,
benefcios e passos para a criao de uma WBS. O Departamento de Defesa Americano
utiliza 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).
25
2. Colocar no segundo nvel (nvel 1, tambm chamado de primeiro nvel de
decomposio) as fases que estabelecem o ciclo de vida do projeto
26
4. Identificar os subprodutos necessrios para que seja alcanado o sucesso do
projeto 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 escopo
do projeto (Project Charter e Declarao de Escopo) assim como entrevistar clientes e
usurios, de forma a identificarmos os subprodutos de cada fase. Caso o nmero de
subprodutos 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 subprodutos
que 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 mais
ou menos detalhado.
Para o controle do projeto, podem ser necessrios, por exemplo:
Reunies, tais como as de partida do projeto (Kick-off Meeting) e de
acompanhamento (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 como
a identificao de riscos, podem ser desenvolvidos neste nvel de detalhe e se
possvel atribuir a responsabilidade para a execuo do mesmo. Se a resposta for
negativa, decompor o elemento da WBS, subdividindo-o em componentes menores,
mais manejveis, at que os subprodutos estejam definidos em detalhe suficiente
para suportar o desenvolvimento dos processos de gerenciamento do projeto
(planejar, executar, controlar e encerrar).
_____________________________________________________________________________________
Gerncia de Escopo de Projetos
27
Os elementos nos nveis mais baixos da WBS (aqueles que no foram
decompostos), so denominados pacotes de trabalho (work packages), sendo a base
lgica para a definio de atividades, designao de responsabilidades, estimativa de
custos e planejamento de riscos. Ateno que no necessrio que a WBS seja
simtrica, ou seja, que todos os subprodutos sejam decompostos at o mesmo nvel.
Quando um determinado elemento da WBS for ser contratado a uma empresa
externa ao projeto, ele no necessita ser decomposto na WBS em subprodutos, uma vez
que 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 o
gerenciamento do mesmo a algum membro da equipe, transformando-o em um
subprojeto. responsabilidade do gerente desse subprojeto efetuar o detalhamento.
Algumas vezes o gerente do projeto, mesmo para elementos da WBS terceirizados ou
subprojetos, decide incorporar o detalhamento dos mesmos na WBS do projeto mestre.
Esta deciso, de detalhar ou no, nos dois exemplos citados, depender do rigor
necessrio 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 a
elaborao de uma WBS no projeto de uma nova bicicleta. Nesse exemplo, a
Fabricao do Prottipo ser contratada externamente e, portanto, no foi detalhada
pois o rigor necessrio foi considerado baixo.
_____________________________________________________________________________________
Gerncia de Escopo de Projetos
28
_____________________________________________________________________________________
Gerncia de Escopo de Projetos
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. Esta
WBS ser utilizada como entrada para o planejamento de outras reas do gerenciamento
do projeto.
Aps termos uma verso da WBS em que foram levadas em considerao as
necessidades das outras reas de gerenciamento, devemos realizar uma validao da
estrutura gerada. No prximo subitem temos alguns mandamentos que nos ajudam
nessa validao.
30
Manual 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 WBS
para que fique bem explcito o trabalho a ser realizado. O Dicionrio da WBS o
documento que define e / ou descreve o trabalho a ser realizado em cada pacote de
trabalho da WBS.
V - Decompors at o nvel de detalhe (pacote de trabalho) que permita o
planejamento e controle do trabalho necessrio para a entrega do subproduto.
O planejamento e controle incluem: escopo (verificao e controle de
mudanas); 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 planejamento
e 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 adianta
decompor o escopo em subprodutos que durem 1 hora para serem gerados se o controle
ser realizado semanalmente. Por outro lado, foi citado anteriormente que os fatores
riscos e custos associados so determinantes do rigor a ser aplicado nos controles.
Desta forma, caso um projeto tenha deliverables com altos nveis de incerteza (que
implicam em altos riscos) e custos elevados, os controles necessrios demandaro uma
decomposio extremamente detalhada. Como exemplo, a WBS de um projeto de
construo de um veculo lanador de satlites (que custa algumas centenas de milhes
de dlares) ser muito mais detalhada do que a WBS da construo de uma casa prfabricada 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 realmente
componentes dos elementos pais. Por exemplo, o fato de um treinamento depender de
um manual do equipamento ter sido disponibilizado no quer dizer que faa parte do
treinamento a elaborao do manual.
VIII Decompors de forma que a soma dos subprodutos dos elementos
componentes (filhos) corresponda ao subproduto do elemento pai (Mandamento
dos 100%).
Ao decompor um subproduto, nenhuma parte dele deve ser esquecida. Lembrese que a soma dos subprodutos componentes deve ser equivalente ao subproduto que foi
decomposto. Por exemplo ao decompor um Estudo de Viabilidade da fase de
Concepo, no poderamos esquecer do Relatrio conclusivo do estudo.
Gerncia de Escopo de Projetos
31
IX - No decompors em somente um subproduto
Um elemento da WBS no deve ter somente um componente (filho). De acordo
com o mandamento anterior, se um elemento tem somente um componente, ele igual
ao pai. Se for, porque represent-lo duas vezes? Quando isso ocorrer, verifique se, na
realidade, 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 subproduto
No podemos ter um elemento como (filho) componente de mais um subproduto
(pai). Por exemplo, se para ministrarmos dois treinamentos utilizarmos a mesma
apostila, no devemos coloc-la como subproduto dos dois treinamentos a elaborao
da mesma. importante ressaltar que podemos ter elementos com o mesmo nome
compondo subprodutos diferentes, mas cada um com um significado diferente. Por
exemplo, na figura a seguir, temos o mesmo nome em vrios subprodutos.
32
Top-down X Bottom-up
Foi apresentada acima uma estratgia para elaborao de uma WBS, utilizando a
tcnica 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 (nvel
de 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 da
WBS:
1. Liste os subprodutos do projeto.
2. Agrupe os subprodutos relacionados entre si para criar um nvel acima que
contenha de dois a oito subprodutos por grupo. O nome do elemento superior,
criado em razo do agrupamento, deve sintetizar as entregas dos elementos
agrupados.
3. Agrupe os elementos do nvel mais alto, criado no passo 2, criando um nvel
acima, 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.
33
Para 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 tambm
pode ser implementado em um editor de textos. Um modelo de Dicionrio da WBS
pode ser visto abaixo.
A especificao de um pacote de trabalho contm informaes sobre o produto a
ser gerado, podendo conter figuras, grficos ou textos. As especificaes podem ser do
seguinte tipo:
34
utilizado um formulrio pr-impresso, de acordo com o
modelo no Anexo II. Cada obra receber um nmero, que ser
o seu identificador na pgina da internet e nos CD-ROMs.
EXEMPLO 2
Pacote de Trabalho
Descrio
3.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 100
pessoas, com durao de 2 horas. O buffet, cardpio e bebidas
devem ser aprovados pelo Depto de Marketing.
EXEMPLO 3
Pacote de Trabalho
2.3.1
Requisio
Materiais
de
Descrio
A requisio de materiais deve atender s normas da
CEN e da INB seguindo os rigorosos padres de controle de
qualidade estipulados no documento : Guia Tcnico de
Qualidade de Materiais para Instalaes de Plantas
Nucleares, fornecido pelo cliente, junto ao memorial tcnico
de especificaes.
35
Inspees
A verificao feita atravs de inspees ou auditorias que verificam os
resultados do trabalho e vo assegurar que eles foram completados, realizados correta e
satisfatoriamente e esto conforme os requisitos definidos. Toda a documentao dos
deliverables, como planos, especificaes, documentos tcnicos e desenhos, tambm
Gerncia de Escopo de Projetos
36
deve 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 de
seus interessados (stakeholders). A formalidade da aceitao tem dois objetivos
principais:
9
Cuidado na aceitao: a formalidade faz com que o
responsvel pela aceitao (principalmente o cliente interno que no est
desembolsando recursos financeiros como contrapartida ao recebimento dos
deliverables) tenha um maior cuidado na validao dos produtos e servios que esto
sendo 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 / ou
extremadas ocorrerem, uma simples assinatura (ou a ausncia dela) pode ser o
diferencial entre o amadorismo e o profissionalismo; e
9
Documentao: deixar registrado quem aceitou o deliverable,
permitindo a continuidade do projeto, principalmente a execuo das atividades
dependentes dessa aceitao.
Se o projeto for finalizado antes do trmino (abortado), o processo de verificao
do 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 mais
importantes do projeto. O gerente do projeto pode tomar a deciso de quais entregas
devem ser formalizadas e de que maneira. Podemos utilizar uma mensagem (e-mail) ou
a assinatura em uma ata de reunio para que o responsvel formalize o aceite ou utilizar
um documento padronizado.
37
APLICADO
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, em
projetos 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 Charter ou
na 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 na
solicitao, avaliao ou autorizao de alteraes de escopo do projeto.
Um exemplo do Plano pode ser visto no anexo.
39
1. Uma alterao de escopo pode ser solicitada tanto pelo cliente como
pela equipe do projeto?
Resposta: Sim. A necessidade de uma alterao de escopo pode partir de
qualquer lugar. O fundamental que seja cumprido o Plano de Gerenciamento de
Escopo no que tange aos procedimentos a serem seguidos. Caso a equipe do projeto
verifique que uma mudana no escopo do projeto possa vir a beneficiar
consideravelmente o escopo do produto do cliente, ela deve, antes de elaborar um
pedido de alterao, estimar os impactos da mudana, de forma a no gerar
expectativas no cliente de algo cujo custo-benefcio no seja compensador.
2. Quem autoriza as alteraes de escopo do projeto o Gerente do
Projeto?
Resposta: Normalmente no, exceto quando ele recebe delegao para tal ou
em projetos decorrentes de contrato em que, dentro do oramento e prazo
estabelecidos, o gerente tem alguma autonomia, desde que no modifique o escopo do
produto a ser entregue ao cliente.
3.
Resposta: Sempre que algum usurio vier com um dos pedidos citados acima
na pergunta 6, a equipe do projeto deve invocar o grande Guru NO, respondendo: Isso NO comigo, temos que seguir o previsto no Plano de Gerenciamento de
Escopo.
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 "Correspondncia
Eletrnica". Esse servio consistiria em receber documentos (contas, cartas, faturas,
telegramas, propagandas etc.) dos clientes em meio magntico (e-mail, site dos Correios
na Internet ou EDI Electronic Data Interchange) para que estes fossem transmitidos
eletronicamente para as agncias mais prximas dos destinatrios, onde seriam
impressos e entregues aos mesmos, com maior rapidez e segurana, reduzindo tambm
o custo para os nossos clientes. Os documentos recebidos nas agncias no poderiam ser
repassados para o destinatrio final por meio eletrnico, sendo de responsabilidade da
agncia a impresso.
Aps ter sido proposto e aprovado pelo Conselho de Administrao para
incluso no Plano Estratgico da empresa, o Presidente determinou ao Diretor
Executivo que desenvolvesse um projeto que propiciasse aos Correios ter esse servio
disponvel 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 de
viabilidade correspondente, em que o investimento tivesse o retorno financeiro
(payback period) em at 5 anos.
41
Empresa Correios S.A
Nome do Projeto: Correspondncia Eletrnica nos Correios
Termo de Abertura do Projeto
Elaborado por: Carlos Magno da S. Xavier Data: 08/08/2004
Aprovado por: Diretor Executivo
Verso: 01
1.1
O Sr. Luiz Fernando Xavier ser o gerente deste projeto, tendo autoridade para
utilizar os recursos financeiros da empresa, conforme limitao do oramento do projeto
e fluxo de caixa da empresa. Est autorizado tambm a recrutar pessoal dos
departamentos da Agncia Central e da Diretoria de Tecnologia da Informao. No caso
de necessidade de correspondncia oficial com rgos do Governo Federal, Estadual ou
Municipal, a Assessoria de Comunicaes deve ser consultada.
1.4
42
1.5
Acompanhamento do projeto
43
Empresa Correios S.A
Nome do Projeto: Correspondncia Eletrnica nos Correios
Declarao do escopo do projeto (Scope Statement)
Elaborado por: Carlos Magno da S. Xavier Data: 28/08/2004
Aprovado por: Diretor Executivo
Verso: 01
Diretor de TI
Diretor de Marketing
Gerente do Projeto
1.1
Produto do Projeto
44
das sugestes resultantes do piloto, ser realizada a implantao nas demais
unidades.
d) O marketing ser contratado externamente, devendo o planejamento do mesmo
ser aprovado junto com a homologao da soluo.
e) O projeto, depois de implantado, ser acompanhado pela equipe do projeto por
quatro meses, ao final do qual ser emitido um relatrio do desempenho da
soluo.
f) No incio da operao estaro utilizando o novo servio, pelo menos os dez
maiores clientes dos Correios e, prontas para impresso de documentos 50% das
Agncias Postais.
1.4
Implantao
Fechamento
1.5
Deliverables
Estudo de viabilidade
Especificao de equipamentos e softwares
Contratos
Customizao de softwares
Manual de Procedimentos
Plano de Marketing
Plano de Contingncia
Homologao da soluo
Marketing do produto
Call Center
Implantao Piloto
Implantao nas demais unidades
Teste Integrado
Relatrio inicial do desempenho da soluo
implantada
Relatrio do Projeto
Excluses de escopo
No faz parte do escopo deste projeto:
1.6
At o dia 28/11/2004 estar concludo o projeto de Ampliao da Infraestrutura da Rede de Computadores dos Correios;
At o dia 28/02/2005 ser regulamentada a correspondncia eletrnica dos
Correios, passando a ter validade jurdica;
Gerncia de Escopo de Projetos
1.7
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; e
distribuio; e
Sero utilizadas as Agncias da cidade de Niteri como implantao piloto,
de forma a validar a implementao da soluo.
Restries do projeto
Acompanhamento do projeto
Aprovao:
Gerncia de Escopo de Projetos
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. As
premissas constantes do Project Charter foram validadas e acrescidas de mais uma
durante o processo de Planejamento de Escopo. As restries de tempo e custo,
estabelecidas no Project Charter, passaram a fazer parte dos objetivos na Declarao de
Escopo. Foi acrescentado tambm um objetivo restringindo a implantao do novo
servio, quando do incio da operao do sistema, aos dez maiores clientes dos Correios
e a 50% das Agncias Postais.
Prximo passo:
Aps os principais interessados terem assinado a Declarao de Escopo, o
escopo deve ento ser detalhado atravs da elaborao da WBS, que definir a base de
referncia para o escopo.
47
Empresa Correios S.A
Nome do Projeto: Correspondncia Eletrnica nos Correios
Estrutura Analtica do Projeto (Work Breakdown Structure)
Elaborado por: Carlos Magno da S. Xavier Data: 10/09/2004
Aprovado por: Diretor de TI
Verso: 01
Diretor de Marketing
Gerente do Projeto
1. Projeto "Correspondncia Eletrnica nos Correios"
1.1. Gerenciamento do projeto
1.1.1. Plano do Projeto
1.1.1.1. Escopo
1.1.1.1.1. Declarao de Escopo
1.1.1.1.2. WBS
1.1.1.1.3. Dicionrio da WBS
1.1.1.2. Cronograma
1.1.1.3. Oramento
1.1.1.4. Matriz de Atribuio de Responsabilidades
1.1.1.5. Plano de Gerenciamento de Recursos Humanos
1.1.1.6. Plano de Resposta a Riscos
1.1.1.7. Plano de Gerenciamento da Qualidade
1.1.1.8. Plano de Gerenciamento das Comunicaes
1.1.1.9. Plano de Gerenciamento das Aquisies
1.1.1.10. Plano Integrado de Mudanas
1.1.1.11. Apresentao do Plano do Projeto
1.1.2. Controle
1.1.2.1.Reunies
1.1.2.2.Relatrios
1.1.2.3. Site na Intranet
1.2. Estudo de Viabilidade
1.2.1. Estudo viabilidade
1.2.1.1. Viabilidade Tcnica
1.2.1.1.1. Relatrio opes de tecnologia
1.2.1.1.2. Relatrio fornecedores potenciais
1.2.1.2.Viabilidade Econmica
1.2.1.2.1. Relatrio da pesquisa com os clientes
1.2.1.2.2. Medida dos impactos nos negcios
1.2.1.2.3. Restries legais
1.2.1.2.4. Definio Agncias centralizadoras
1.2.1.2.5. Avaliao do custo
1.2.1.2.6. Payback Period
1.2.1.3.Relatrio consolidado
1.2.2. Apresentao do Estudo de viabilidade
1.3. Definio
1.3.1. Especificao de equipamentos
1.3.2. Especificao de softwares
1.4. Contratao
Gerncia de Escopo de Projetos
48
1.4.1. Solicitao de Propostas
1.4.2. Relao de fornecedores selecionados
1.4.3. Negociao contratos
1.4.4. Contratos
1.5. Implementao da soluo
1.5.1. Instalao hardware e software para desenvolvimento
1.5.2. Customizao de softwares
1.5.3. Testes
1.5.4. Manual de Procedimentos
1.5.5. Preparao Call Center
1.5.6. Plano de Contingncia
1.5.7. Plano de Marketing
1.5.8. Homologao da soluo
1.6. Implantao da soluo
1.6.1. Marketing do produto
1.6.2. Call Center
1.6.3. Implantao Piloto
1.6.3.1.Instalao hardware e software para operao
1.6.3.2.Treinamento
1.6.3.3. Acompanhamento da operao Piloto
1.6.3.4.Relatrio do Piloto
1.6.4. Atualizao da soluo em funo do piloto
1.6.5. Implantao demais unidades (subprojeto)
1.6.6. Relatrio inicial do desempenho da soluo implantada
1.7. Fechamento
1.7.1. Encerramento de contratos
1.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
________________________________________
ASSINATURA DO DIRETOR DE MARKETING
49
Comentrio:
A WBS foi elaborada a partir das fases e dos deliverables principais listados na
declarao de escopo. O detalhamento da WBS depender do tamanho e complexidade
do 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 de
Escopo. Abaixo segue um exemplo de Plano para o caso acima.
Empresa Correios S.A
Nome do Projeto: Correspondncia Eletrnica nos Correios
Plano de Gerenciamento do Escopo
Elaborado por: Carlos Magno da S. Xavier Data: 05/09/2004
Verso: 01
Aprovado por: Diretor de TI
Diretor de Marketing
Gerente do Projeto
I INTRODUO
II O GERENCIAMENTO DE ALTERAES DE ESCOPO
O trabalho a ser realizado neste projeto (baseline de escopo) est documentado
na Estrutura Analtica do Trabalho (WBS) e em seu Dicionrio. Nenhum trabalho deve
ser realizado pela equipe do projeto que no esteja definido nesta baseline. Essa WBS
foi elaborada tendo como base a Declarao de Escopo.
Este plano apresenta os procedimentos que sero usados para gerenciar as
alteraes no escopo do projeto, ou seja, como as mudanas do escopo sero
identificadas, classificadas e, se autorizadas, integradas ao projeto. O objetivo garantir
que sejam coletadas todas as informaes relacionadas mudana solicitada, alm de
que seja realizada, para cada alterao proposta, uma avaliao dos impactos no projeto
(custo, prazo, qualidade e risco), assim como em seus objetivos. As alteraes propostas
de escopo devem ter suporte nas metas fundamentais de negcio da empresa, em funo
das quais o projeto foi autorizado.
II.1 - PROCEDIMENTOS
Quando alguma necessidade de mudana de escopo for identificada, deve ser
gerada uma Solicitao de Mudana de Escopo (SME). S podem emitir solicitaes de
mudanas os Chefes de Departamento. Esta solicitao ser analisada pelo gerente do
projeto, que avaliar os impactos da mesma no projeto e a registrar no espao
destinado a este fim. O gerente do projeto poder autorizar alteraes de escopo que no
tenham impacto no custo e no prazo total do projeto, assim como na qualidade do
produto, se for o caso. Caso contrrio, aps o registro desse impacto na SME, o gerente
deve envi-la para aprovao ou no pelo Diretor Executivo.
Abaixo seguem as informaes que devem estar contidas na SME.
Gerncia de Escopo de Projetos
50
Empresa Correios S.A
Solicitao de Mudana de Escopo n ....
Projeto:
Solicitado por:
Descrio da mudana solicitada:
Ramal:
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:
51
3.2 EXERCCIO
Tendo em vista o texto abaixo, elaborar o Termo de abertura
correspondente:
No momento atual, em que vrias organizaes esto passando por
mudanas estruturais em direo a uma orientao por projetos, torna-se
mais evidente a necessidade de se estabelecer metodologias de gesto que
conduzam ao sucesso ou que, pelo menos, aumentem a probabilidade de
atingir o sucesso em seus projetos. Para tal, torna-se necessria a
capacitao de profissionais das Organizaes em ferramentas e tcnicas
para 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 de
portflio tm registrado uma melhora contnua na eficincia de seus
projetos, 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 uma
reduo de, no mnimo, 10% nos custos dos projetos no prximo ano, tendo
como foco principal a otimizao dos recursos fsicos e financeiros da
empresa, por meio de um melhor gerenciamento dos projetos, o Diretor
Executivo da empresa determinou a realizao de um treinamento em
gerenciamento 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 ter
como base a metodologia methodware de gerenciamento de projetos, cuja
contratao estar concluda pelo Departamento financeiro em 10 dias.
O treinamento ser aberto pelo diretor executivo e fechado pelo
presidente da empresa e dever estar concludo, no mximo, em dois
meses. O Sr. Jos das Couves ser o gerente do projeto.
52
Exerccio
No texto da pgina anterior, identifique:
1. Justificativa (no precisa copiar, podendo indicar no texto)
2. Descrio do Produto
3. Designao do Gerente
4. Premissas
5. Restries
53
Soluo:
O documento abaixo representa a autorizao para incio do projeto.
Beware Consultoria Empresarial Ltda
Nome do Projeto: Treinamento em Gerenciamento de Projetos
Termo de Abertura do Projeto
Elaborado por: Carlos Magno da S. Xavier Data: 22/09/2004
Aprovado por: Diretor Executivo
Verso: 01
1.1
O Sr. Jos das Couves ser o gerente deste projeto. Sua escolha foi realizada
em razo de sua experincia na organizao de outros treinamentos da empresa.
54
1.4
55
4. Novas premissas
56
Soluo:
Aps as reunies para a definio do escopo do cliente e da estratgia de
conduo, foi elaborada a declarao de escopo abaixo:
Beware Consultoria Empresarial Ltda
Nome do Projeto: Treinamento em Gerenciamento de Projetos
Declarao de Escopo
Elaborado por: Jos das Couves
Data:
Aprovado por: Gerente do Projeto
Verso:
Representantes dos Departamentos
de TI, Engenharia e Recursos Humanos
1. Justificativa do projeto
Este projeto de treinamento foi autorizado com o objetivo de obter uma reduo de,
no mnimo, 10% nos custos dos projetos no prximo ano, tendo como foco principal a
otimizao dos recursos fsicos e financeiros da empresa, por meio de um melhor
gerenciamento dos projetos.
2. Descrio do produto do projeto
Este projeto tem como escopo a realizao de um treinamento em gerenciamento de
projetos (GP), utilizando a metodologia methodware, para 30 profissionais que
trabalham em projetos nos Departamento de TI e Engenharia. O treinamento, com uma
carga horria de 32 horas, deve conter os seguintes mdulos: Importncia do GP,
Conceitos bsicos do GP; Iniciando o projeto, Planejando o projeto, Executando o
projeto, Controlando o projeto e encerrando o projeto. Para sedimentao dos
conhecimentos deve ser utilizado um exerccio prtico durante o treinamento em que os
alunos tenham condies de, pelo menos, elaborar o planejamento de um projeto. Os
alunos devero receber como material didtico uma apostila, cpia dos slides da
apresentao e o exerccio prtico. Devem ser providenciados dois coffee breaks para
cada dia de treinamento. Ser aplicada uma prova para avaliao do grau de
aprendizado dos alunos.
3. Critrios de aceitao do produto
O curso deve atingir os seguintes resultados para ser considerado bem sucedido:
a. Aprovar 90% dos alunos
b. Obter 85% de avaliaes positivas dos alunos
c. Cumprir 100% do contedo programtico no prazo estabelecido
4. Escopo no includo no projeto
A divulgao e convite s pessoas para o evento, assim como controlar a presena
dos participantes e a emisso de certificados, que estar a cargo do Departamento
de Recursos Humanos.
O fornecimento de almoo para os participantes.
5. Ligaes com outros projetos
Este projeto tem ligao com o projeto de Implantao do Escritrio de Projetos,
principalmente no que tange metodologia que ser abordada no treinamento.
57
6. Estratgias de conduo do projeto
a) O treinamento dever ser realizado em 4 dias teis e consecutivos, sendo
ministrado por um dos profissionais da empresa que j possua a certificao
PMP (Project Management Professional). O prprio instrutor designado dever
preparar o material didtico, que ser reproduzido na grfica da empresa.
b) A equipe de planejamento far uma reunio com o Departamento de Rh para
definio da data e do instrutor que ir ministrar o treinamento.
c) O coffee break ser contratado externamente.
d) A avaliao do treinamento (contedo, instrutor, recursos audiovisuais e
acomodaes) ser feita no ltimo dia de aula, aps a concluso do ltimo
mdulo. A prova ser aplicada uma semana depois do trmino das aulas.
7. Responsabilidades dos setores envolvidos
Os Departamentos de TI e Engenharia informaro, at o dia xx/xx/xxxx, para o
Departamento de Recursos Humanos, a relao do pessoal que participar do
treinamento, devendo cada um apresentar 15 funcionrios.
8. Premissas (hipteses) e restries ao projeto
Premissas (hipteses)
Restries
O treinamento ser aberto pelo diretor O treinamento dever ser realizado nas
executivo e fechado pelo presidente da
instalaes da empresa.
empresa.
O treinamento dever estar concludo, no
A sala de aulas da empresa possui os mximo, em dois meses.
recursos audiovisuais necessrios e estar
disponvel para o treinamento.
A
contratao
da
metodologia
methodware estar concluda pelo
Departamento financeiro at o dia
xx/xx/xx.
58
Exerccio EAP
Para a Declarao de Escopo da pgina anterior, fazer a Estrutura Analtica
do Projeto (EAP).
59
60
IDENTIFICAO
WBS
PACOTE
DE
TRABALHO
ESPECIFICAO
CRITRIO
ACEITAO
DE
61
Soluo:
Beware Consultoria Empresarial Ltda
Nome do Projeto: Treinamento em Gerenciamento de Projetos
Dicionrio da Estrutura Analtica do Projeto
Elaborado por: Jos das Couves
Data:
Verso: 01
Aprovado por: Gerente do Projeto e
representantes dos Departamentos de TI,
Engenharia e Recursos Humanos
IDENTIFICAO
WBS
1.1.2
1.1.3
1.1.4
1.1.5
PACOTE
DE
TRABALHO
CRITRIO
ACEITAO
ESPECIFICAO
Documento estabelecendo o
Oramen
planejamento de recursos materiais e
to
humanos com respectivos custos
DE
Conter todos
os produtos e
servios a serem
entregues;
Ser aprovada
pela equipe de
planejamento do
projeto e pelo
patrocinador.
Ata
aprovada pela
equipe de
planejamento do
projeto e pelo
patrocinador;
Ser formalmente
aceita
pelo
instrutor.
Conter as
informaes
previstas e ser
apresentado nos
formatos
indicados;
Ser
aprovado
pela equipe de
planejamento do
projeto e pelo
patrocinador.
Todos os
itens de custos
orados;
62
IDENTIFICAO
WBS
PACOTE
DE
TRABALHO
CRITRIO
ACEITAO
ESPECIFICAO
associados;
Deve ser entregues o oramento
consolidado por item de custo, o
oramento de custos diretos por atividade e
o oramento de custos mensais do projeto,
todos na forma de planilha do Excel.
1.2.1
1.2.2.1
1.2.2.2
1.2.2.3
Reserva
sala
DE
Custos de
aquisies acima
de R$ 2.000,00
fundamentados por
propostas
ou
cotaes
dos
fornecedores;
Ser aprovado pela
equipe
de
planejamento do
projeto e pelo
patrocinador.
E-mail do
setor
correspondente
confirmando a
reserva.
Conter as
informaes
previstas e ser
apresentada
no
formato indicado.
Conter as
informaes
previstas e serem
apresentados
no
formato indicado.
Conter as
informaes
previstas e ser
apresentado
no
formato indicado.
63
IDENTIFICAO
WBS
PACOTE
DE
TRABALHO
1.2.2.4
Prova
1.2.2.5
Reproduo
e
montagem
material
1.2.3
Contratao
coffee
break
1.2.4
Questionrio de
avaliao
CRITRIO
ACEITAO
ESPECIFICAO
DE
Atender s
especificaes.
Conter as
informaes
previstas e ser
apresentado
no
formato,
quantidade e prazo
indicados.
Contrato
assinado entre as
partes.
Atender s
especificaes.
64
IDENTIFICAO
WBS
PACOTE
DE
TRABALHO
1.3.2
Aulas
1.3.3
Coffee
break
1.3.4
Avaliao
do
treiname
nto
1.4.1
Avaliao dos
alunos
(prova)
1.4.2
Relatrio
do
ESPECIFICAO
CRITRIO
ACEITAO
DE
Atender s
Deve ter como base a metodologia
especificaes;
methodware, seguindo o sumrio:
Importncia do GP, Conceitos bsicos Obter mdia
do GP; Iniciando o projeto, Planejando
igual ou superior
o projeto, Executando o projeto,
a 8,5 na
Controlando o projeto e Encerrando o
avaliao do
projeto. com foco no pblico alvo de
treinamento
gerentes de projetos dos Departamentos
(1.3.4)
de TI e Engenharia
Cumprir 100%
O treinamento ser aberto pelo diretor
do contedo
executivo e fechado pelo presidente da
programtico
empresa
As aulas devem ser distribudas em 4
dias consecutivos, com durao de 8h
em cada, em datas definidas em 1.1.3;
Utilizar a apostila (1.2.2.1) os slides
(1.2.2.2) e o exerccio prtico (1.2.2.3),
mantendo a diretriz de unir a teoria
prtica.
Servido para 31 pessoas (30
Atender s
participantes e o instrutor), por empresa especificaes.
contratada, constando de 2 coffee
breaks de 15 minutos em cada dia de
aula (1.3.2), servindo bebidas quentes e
frias no alcolicas, alm de petiscos
doces e salgados.
Atender s
Atender s
documentao do histrico do projeto,
especificaes.
Gerncia de Escopo de Projetos
65
IDENTIFICAO
WBS
PACOTE
DE
TRABALHO
projeto
CRITRIO
ACEITAO
ESPECIFICAO
DE
Aprovao
do
relatrio
pelo
Diretor Executivo
66
67
68
69
todo o contedo do treinamento (texto e imagens), em duas verses: CD-ROM e
Intranet. Ambas as verses tero o mesmo contedo, possuindo apenas as seguintes
diferenas: a verso em CD-ROM conter trechos de vdeos fornecidos pela Empresa
Helma Chique; e a verso Intranet se comunicar com o gerenciador de treinamento
utilizado pela Empresa, a fim de que seja possvel registrar informaes sobre o acesso
ao treinamento pelos funcionrios. O projeto tambm prev a criao de uma
apresentao, no formato PowerPoint, contendo um resumo do contedo das verses
CD-ROM e Intranet.
70
71
e boutique com acessrios apropriados. O estabelecimento, a ser entregue pronto para o
seu funcionamento, deve ser de altssimo luxo, padro cinco estrelas, para atender as
classes A e B. As sutes sero temticas, atendendo aos mais variados clientes e gostos.
Os insumos para a construo devero atender aos padres internacionais, devido s
caractersticas do pblico alvo.
<Nome da Empresa>
Projeto: <nome do projeto>
<Nome do Documento>
Preparado por
Aprovado por
Verso:
Data:
72
73
Controle integrado de mudanas / Integrated Change Control [Processo]. O processo
de reviso de todas as solicitaes de mudana, aprovao de mudanas e controle de
mudanas em entregas e ativos de processos organizacionais.
Criar EAP (Estrutura analtica do projeto) / Create WBS (Work Breakdown Structure)
[Processo]. O processo de subdiviso das principais entregas do projeto e do trabalho do
projeto em componentes menores e mais facilmente gerenciveis.
Critrios / Criteria. Normas, regras ou testes em que uma opinio ou deciso pode se
basear ou pelos quais um produto, servio, resultado ou processo pode ser avaliado.
Critrios de aceitao / Acceptance Criteria. Os critrios, inclusive requisitos de
desempenho e condies essenciais, que devem ser atendidos antes que as entregas do
projeto sejam aceitas.
Declarao do escopo do projeto / Project Scope Statement [Sadas/Entradas]. A
descrio do escopo do projeto, que inclui as principais entregas, os objetivos, suposies
e restries do projeto e uma declarao do trabalho, que fornece uma base documentada
para futuras decises do projeto e para confirmar ou desenvolver um entendimento comum
do escopo do projeto entre as partes interessadas. A definio do escopo do projeto o
que precisa ser realizado.
Declarao do trabalho (DT) / Statement of Work (SOW). Uma descrio dos produtos,
servios ou resultados a serem fornecidos.
Decomposio / Decomposition [Tcnica]. Uma tcnica de planejamento que subdivide
o escopo do projeto e as entregas do projeto em componentes menores e mais facilmente
gerenciveis, at que o trabalho do projeto associado realizao do escopo do projeto e
ao fornecimento das entregas seja definido em detalhes suficientes para dar suporte
execuo, ao monitoramento e ao controle do trabalho.
Definio do escopo / Scope Definition [Processo]. O processo de desenvolvimento de
uma declarao do escopo detalhada do projeto como base para futuras decises do
projeto.
Descrio do escopo do produto / Product Scope Description. A descrio
documentada do escopo do produto.
Desenvolver o termo de abertura do projeto / Develop Project Charter [Processo]. O
processo de desenvolvimento do termo de abertura do projeto que formalmente autoriza
um projeto.
Dicionrio da estrutura analtica do projeto / Work Breakdown Structure Dictionary.
Um documento que descreve cada componente da estrutura analtica do projeto (EAP).
Para cada componente da EAP, o dicionrio da EAP inclui uma breve definio do escopo
ou declarao do trabalho, entrega(s) definida(s), uma lista de atividades associadas e
uma lista de marcos. Outras informaes podem incluir: organizao responsvel, datas
de incio e de concluso, recursos necessrios, uma estimativa de custos, nmero de
cobrana, informaes do contrato, requisitos de qualidade e referncias tcnicas para
facilitar o desempenho do trabalho.
Elaborao progressiva / Progressive Elaboration [Tcnica]. Melhoria e detalhamento
contnuos de um plano conforme informaes mais detalhadas e especficas e estimativas
mais exatas tornam-se disponveis conforme o projeto se desenvolve e, portanto, produo
de planos mais exatos e completos que resultam de sucessivas iteraes do processo de
planejamento.
Entrega / Deliverable [Sadas/Entradas]. Qualquer produto, resultado ou capacidade para
realizar um servio exclusivo e verificvel que deve ser produzido para terminar um
processo, uma fase ou um projeto. Muitas vezes utilizado mais especificamente com
referncia a uma entrega externa, que uma entrega sujeita aprovao do patrocinador
ou do cliente do projeto. Veja tambm produto, servio e resultado.
Escopo / Scope. A soma dos produtos, servios e resultados a serem fornecidos na forma
de projeto. Veja tambm escopo do projeto e escopo do produto.
Escopo do produto / Product Scope. As caractersticas e funes que descrevem um
produto, servio ou resultado.
Escopo do projeto / Project Scope. O trabalho que deve ser realizado para entregar um
produto, servio ou resultado com as caractersticas e funes especificadas.
74
Especificao / Specification. Um documento que especifica, de maneira completa,
precisa e verificvel, requisitos, projeto, comportamento ou outras caractersticas de um
sistema, componente, produto, resultado ou servio e, com freqncia, os procedimentos
para determinar se essas clusulas foram satisfeitas. Exemplos: especificao de
requisitos, especificao de projeto, especificao de produto e especificao de testes.
Estrutura analtica do projeto (EAP) / Work Breakdown Structure (WBS)
[Sadas/Entradas]. Uma decomposio hierrquica orientada entrega do trabalho a ser
executado pela equipe do projeto para atingir os objetivos do projeto e criar as entregas
necessrias. Ela organiza e define o escopo total do projeto. Cada nvel descendente
representa uma definio cada vez mais detalhada do trabalho do projeto. A EAP
decomposta em pacotes de trabalho. A orientao da hierarquia para a entrega inclui
entregas internas e externas. Veja tambm pacote de trabalho, conta de controle, estrutura
analtica do projeto contratado e estrutura analtica do resumo do projeto.
Estrutura analtica do projeto contratado (EAPC) / Contract Work Breakdown
Structure (CWBS)
[Sadas/Entradas]. Uma parte da estrutura analtica do projeto desenvolvida e mantida por
um fornecedor que assina contrato para fornecer um subprojeto ou um componente do
projeto.
Fase / Phase. Veja fase do projeto.
Fase do projeto / Project Phase. Um conjunto de atividades do projeto* relacionadas de
forma lgica que geralmente culminam com o trmino de uma entrega importante. Na
maioria dos casos, as fases do projeto (tambm chamadas de fases) so terminadas
seqencialmente, mas podem se sobrepor em algumas situaes do projeto. As fases
podem ser subdivididas em subfases e depois em componentes; se o projeto ou parte do
projeto estiver dividido em fases, essa hierarquia far parte da estrutura analtica do
projeto. Uma fase do projeto um componente do ciclo de vida do projeto. Uma fase do
projeto no um grupo de processos de gerenciamento de projetos.
Gerente de projetos (GP) / Project Manager (PM). A pessoa designada pela organizao
executora para atingir os objetivos do projeto.
Influenciador / Influencer. Pessoas ou grupos que no esto diretamente relacionados
aquisio ou ao uso do produto do projeto, mas que, devido sua posio na organizao
do cliente, podem influenciar, positiva ou negativamente, no andamento do projeto.
Informaes histricas / Historical Information. Documentos e dados sobre projetos
anteriores que incluem arquivos de projetos, registros, correspondncias, contratos
encerrados e projetos encerrados.
Iniciao do projeto / Project Initiation. Lanamento de um processo que pode resultar
na autorizao e na definio do escopo de um novo projeto.
Iniciador / Initiator. Uma pessoa ou organizao que possui a capacidade e a autoridade
para iniciar um projeto.
Inspeo / Inspection [Tcnica]. Exame ou medida para verificar se uma atividade,
componente, produto, resultado ou servio est de acordo com os requisitos
especificados.
Item de trabalho / Work Item. Este termo no mais usado. Veja atividade e atividade do
cronograma.
Lies aprendidas / Lessons Learned. A aprendizagem obtida no processo de
realizao do projeto. As lies aprendidas podem ser identificadas a qualquer momento.
Tambm consideradas um registro do projeto, que ser includo na base de conhecimento
de lies aprendidas.
Linha de base / Baseline. O plano dividido em fases aprovado (para um projeto, um
componente da estrutura analtica do projeto, um pacote de trabalho ou uma atividade do
cronograma), mais ou menos o escopo do projeto, o custo, o cronograma e as mudanas
tcnicas aprovados. Em geral, refere-se linha de base atual, mas pode se referir
original ou a alguma outra linha de base. Normalmente usada com um modificador (por
exemplo, linha de base dos custos, do cronograma, da medio de desempenho, tcnica).
Veja tambm linha de base da medio de desempenho.
75
Linha de base da medio de desempenho / Performance Measurement Baseline.
Um plano aprovado para o trabalho do projeto em relao ao qual comparada a
execuo do projeto e so
medidos os desvios para o controle do gerenciamento. A linha de base da medio de
desempenho normalmente integra parmetros de escopo, cronograma e custo de um
projeto, mas tambm pode incluir parmetros tcnicos e de qualidade.
Linha de base do escopo / Scope Baseline. Veja linha de base.
Marco / Milestone. Um ponto ou evento significativo no projeto. Veja tambm marco do
cronograma.
Marco do cronograma / Schedule Milestone. Um evento significativo no cronograma do
projeto, como um evento que limita o trabalho futuro ou que termina uma entrega
importante. Um marco do cronograma possui durao nula. s vezes chamado de
atividade-marco. Veja tambm marco.
Modelo / Template. Um documento parcialmente completo em um formato predefinido
que fornece uma estrutura definida para coletar, organizar e apresentar informaes e
dados. Os modelos geralmente se baseiam em documentos criados durante projetos
anteriores. Os modelos podem reduzir o esforo necessrio para realizar um trabalho e
aumentar a consistncia dos resultados.
Mudana solicitada / Requested Change [Sadas/Entradas]. Uma solicitao de
mudana formalmente documentada submetida a aprovao para o processo de controle
integrado de mudanas. Compare com solicitao de mudana aprovada.
Mudanas do escopo / Scope Change. Qualquer mudana no escopo do projeto. Uma
mudana do escopo quase sempre exige um ajuste nos custos ou no cronograma do
projeto.
Objetivo / Objective. Algo em cuja direo o trabalho deve ser orientado, uma posio
estratgica a ser alcanada ou um objetivo a ser atingido, um resultado a ser obtido, um
produto a ser produzido ou um servio a ser realizado.
Pacote de trabalho / Work Package. Uma entrega ou componente do trabalho do projeto
no nvel mais baixo de cada ramo da estrutura analtica do projeto. O pacote de trabalho
inclui as atividades do cronograma e os marcos do cronograma necessrios para terminar
a entrega do pacote de trabalho ou o componente do trabalho do projeto.
Partes interessadas / Stakeholder. Pessoas e organizaes, como clientes,
patrocinadores, organizaes executoras e o pblico, que estejam ativamente envolvidas
no projeto ou cujos interesses possam ser afetados de forma positiva ou negativa pela
execuo ou trmino do projeto. Elas podem tambm exercer influncia sobre o projeto e
suas entregas.
Patrocinador / Sponsor. A pessoa ou o grupo que fornece os recursos financeiros, em
dinheiro ou em espcie, para o projeto.
Planejamento em ondas sucessivas / Rolling Wave Planning [Tcnica]. Uma forma de
planejamento de elaborao progressiva em que o trabalho que ser realizado em curto
prazo planejado em detalhes em um nvel baixo da estrutura analtica do projeto,
enquanto o trabalho distante no futuro planejado em um nvel relativamente alto da
estrutura analtica do projeto. Porm, o planejamento detalhado do trabalho a ser realizado
dentro de mais um ou dois perodos no futuro prximo feito conforme o trabalho est
sendo terminado durante o perodo atual.
Plano de gerenciamento do projeto / Project Management Plan [Sadas/Entradas]. Um
documento formal e aprovado que define como o projeto executado, monitorado e
controlado. Ele pode ser resumido ou detalhado e pode ser formado por um ou mais
planos de gerenciamento auxiliares e outros documentos de planejamento.
Portflio / Portfolio. Um conjunto de projetos ou programas e outros trabalhos agrupados
para facilitar o gerenciamento eficaz desse trabalho a fim de atender aos objetivos de
negcios estratgicos. Os projetos ou programas do portflio podem no ser
necessariamente interdependentes ou diretamente relacionados.
Premissas / Assumptions [Sadas/Entradas]. Premissas so fatores que, para fins de
planejamento, so considerados verdadeiros, reais ou certos sem prova ou demonstrao.
As premissas afetam todos os aspectos do planejamento do projeto e fazem parte da
76
elaborao progressiva do projeto. Freqentemente, as equipes do projeto identificam,
documentam e validam as premissas durante o processo de planejamento. Geralmente, as
premissas envolvem um grau de risco.
Programa / Program. Um grupo de projetos relacionados gerenciados de modo
coordenado para a obteno de benefcios e controle que no estariam disponveis se eles
fossem gerenciados individualmente. Programas podem incluir elementos de trabalho
relacionado fora do escopo dos projetos distintos no programa.
Projeto / Project. Um esforo temporrio empreendido para criar um produto, servio ou
resultado exclusivo.
Relatrios de desempenho / Performance Reports [Sadas/Entradas]. Documentos e
apresentaes que fornecem informaes organizadas e resumidas sobre o desempenho
do trabalho, clculos e parmetros de gerenciamento de valor agregado e anlises de
andamento e progresso do trabalho do projeto. Formatos comuns de relatrios de
desempenho incluem grficos de barras, curvas S, histogramas, tabelas e diagrama de
rede do cronograma do projeto mostrando a situao atual do cronograma.
Requisito / Requirement. Uma condio ou capacidade que deve ser atendida ou
possuda por um sistema, produto, servio, resultado ou componente para satisfazer um
contrato, uma norma, uma especificao ou outros documentos impostos formalmente. Os
requisitos incluem necessidades, desejos e expectativas quantificados e documentados do
patrocinador, do cliente e de outras partes interessadas.
Restrio / Constraint [Entradas]. O estado, a qualidade ou o sentido de estar restrito a
uma determinada ao ou inatividade. Uma restrio ou limitao aplicvel, interna ou
externa ao projeto, que afetar o desempenho do projeto ou de um processo. Por
exemplo, uma restrio do cronograma qualquer limitao ou condio colocada em
relao ao cronograma do projeto que afeta o momento em que uma atividade do
cronograma pode ser agendada e geralmente est na forma de datas impostas fixas. Uma
restrio de custos qualquer limitao ou condio colocada em relao ao oramento
do projeto, como fundos disponveis ao longo do tempo. Uma restrio de recursos do
projeto qualquer limitao ou condio colocada em relao utilizao de recursos,
como quais habilidades ou disciplinas do recurso esto disponveis e a quantidade
disponvel de um determinado recurso durante um prazo especificado.
Resultado / Result. Uma sada dos processos e atividades de gerenciamento de projetos.
Os resultados podem incluir efeitos (por exemplo, sistemas integrados, processo revisado,
organizao reestruturada, testes, pessoal treinado, etc.) e documentos (por exemplo,
polticas, planos, estudos, procedimentos, especificaes, relatrios, etc.). Compare com
produto e servio. Veja tambm entrega.
Servio / Service. Trabalho til realizado que no produz um produto ou resultado
tangvel, como a realizao de uma das funes de negcios que do suporte produo
ou distribuio. Compare com produto e resultado. Veja tambm entrega.
Sistema de controle de mudanas / Change Control System [Ferramenta]. Um
conjunto de procedimentos formais e documentados que define como as entregas e a
documentao do projeto sero controladas, alteradas e aprovadas. Na maior parte das
reas de aplicao, o sistema de controle de mudanas um subconjunto do sistema de
gerenciamento de configurao.
Sistema de gerenciamento de configurao / Configuration Management System
[Ferramenta]. Um subsistema do sistema de gerenciamento de projetos global. um
conjunto de procedimentos formais documentados usados para aplicar orientao e
superviso tcnicas e administrativas para: identificar e documentar as caractersticas
funcionais e fsicas de um produto, resultado, servio ou componente, controlar quaisquer
mudanas feitas nessas caractersticas, registrar e relatar cada mudana e o andamento
de sua implementao e dar suporte auditoria dos produtos, resultados ou componentes
para verificar a conformidade com os requisitos. Ele inclui a documentao, os sistemas de
acompanhamento e os nveis de aprovao definidos necessrios para autorizao e
controle das mudanas. Na maior parte das reas de aplicao, o sistema de
gerenciamento de configurao inclui o sistema de controle de mudanas.
77
Solicitao de mudana / Change Request. Solicitaes para aumentar ou reduzir o
escopo do projeto, modificar polticas, processos, planos ou procedimentos, modificar
custos ou oramentos ou revisar cronogramas. As solicitaes de mudana podem ser
feitas de forma direta ou indireta, por iniciativa externa ou interna e impostas por lei ou
contrato ou opcionais. Somente as mudanas solicitadas formalmente documentadas so
processadas e somente as solicitaes de mudana aprovadas so implementadas.
Subfase / Subphase. Uma subdiviso de uma fase.
Subprojeto / Subproject. Uma parte menor do projeto total, criada quando um projeto
subdividido em componentes ou partes mais facilmente gerenciveis. Os subprojetos so
geralmente representados na estrutura analtica do projeto. Um subprojeto pode ser
chamado de projeto, gerenciado como um projeto e adquirido de um fornecedor. Pode ser
chamado de sub-rede em um diagrama de rede do cronograma do projeto.
Tarefa / Task. Um termo usado para trabalho cujo significado e colocao dentro de um
plano estruturado de um trabalho do projeto variam de acordo com a rea de aplicao,
setor e marca do software de gerenciamento de projetos.
Termo de abertura do projeto / Project Charter [Sadas/Entradas]. Um documento
publicado pelo iniciador ou patrocinador do projeto que autoriza formalmente a existncia
de um projeto e concede ao gerente de projetos a autoridade para aplicar os recursos
organizacionais nas atividades do projeto.
Trabalho / Work. Esforo, empenho ou exerccio fsico ou mental sustentado de
habilidade para superar obstculos e atingir um objetivo.
Usurio / User. A pessoa ou organizao que utilizar o produto ou servio do projeto.
Veja tambm cliente.
78