6

Definindo o Escopo

Neste captulo, iremos detalhar o escopo do nosso projeto, decompondo-o em partes meno-
res e mais fceis de gerenciar.
Conceitos apresentados:
Escopo O Que Pretendemos Fazer?
Escopo Preliminar e Requisitos do Projeto.
Declarao de Escopo do Projeto.
Estrutura Analtica de Projeto e Dicionrio.
Entregas e Fases no MS-Project.

6.1 Escopo O que pretendemos fazer?

Existem quatro aspectos ou vises que merecem ateno em todo projeto:

Produto: entrega ou resultado final esperado;
Projeto: trabalho necessrio para realizar ou construir o produto final;
Partes interessadas: beneficiados ou afetados pelo resultado final ou pela execuo
do projeto; e,
Documentos e prticas: metodologia e ferramentas de gerenciamento de projetos.
Figura 6.1 Aspectos ou vises que devem ser gerenciados no projeto
O escopo de um projeto aquilo que ele pretende fazer. So as entregas e resultados que
pretendemos realizar.
Todo o projeto, portanto, gira em torno do Escopo e de seus Stakeholders. Ao trmino, nin-
gum quer saber de cronogramas e documentos, mas sim dos resultados. Isto , o objetivo do
gerente do projeto entregar benefcios, satisfazendo s partes interessadas!
Isso no quer dizer que a parte de planejamento seja menos importante. No. O planeja-
mento e as demais reas de conhecimento so essenciais para a execuo do escopo e para a sa-
tisfao dos stakeholders. Tenha sempre em mente que o objetivo do projeto criar valor e gerar
benefcios.
Nesse sentido, o escopo a linha mestre a que une todos os aspectos do projeto. A partir da
demanda do negcio, problema a ser resolvido ou oportunidade a ser aproveitada, teremos o
nosso escopo, entregas e resultados.
Com base nesse escopo, partiremos para a definio do trabalho necessrio, tarefas, como
fazer o trabalho, quais recursos empregar e assim por diante, constituindo o restante do planeja-
mento com base no Escopo.
O leitor pode concluir facilmente que se o escopo estiver incompleto ou errado, todos os de-
mais documentos de projeto, que se baseiam nele, sero inteis. De que adianta tarefas e um cro-
nograma que executam um escopo cujos resultados no so o que eu quero? O mesmo vale para
os demais planos.
Portanto, defina bem seu escopo para que o trabalho subsequente no seja desperdiado.

Mr. PROJECT
O planejamento do projeto envolve dois aspectos principais:
O que queremos fazer? (Por que desejamos fazer?)
Como pretendemos fazer?
Somente aps identificar o que o projeto deve entregar em termos de resultado que po-
demos fazer o seu planejamento.
No Termo de Abertura do Projeto, j identificamos o problema e sua justificativa, demanda
de negcio do projeto. Posteriormente, redigimos a misso do projeto e sua declarao de
escopo. O escopo do projeto delimita o que ser feito e o que no ser feito, o que faz parte
do projeto e o que no est incluso. Alm disso, so definidos os requisitos e critrios de
aceitao das entregas.
Figura 6.2 Diferenas entre Termo de Abertura do Projeto e Declarao de Escopo
do Projeto.

Obviamente, para atingir os objetivos do projeto e entregar seus resultados, precisamos

de processos de gesto ou processo orientados para o gerenciamento do projeto nas de-
mais reas do conhecimento no Guia PMBOK. Vale a pena ressaltar a distino entre:
Escopo do PRODUTO: caractersticas e funes que descrevem um produto, servio ou re-
sultado.
Escopo do PROJETO: trabalho que precisa ser realizado para entregar um produto, servio
ou resultado com as caractersticas e funes especificadas.
6.2 Escopo Preliminar e Requisitos do Projeto

6.2.1 O que so requisitos?

Relembrando a definio de sucesso do projeto, segundo HARTMAN (2000), precisamos sa-

tisfazer os stakeholders. Para isso, preciso gerenciar suas expectativas. Grande parte do sucesso
de gerenciar as expectativas est relacionado com a ateno na captura e gerenciamento dos re-
quisitos do produto e do projeto. Vale ressaltar que precisamos agir como consultores, isto ,
precisamos questionar e buscar compreender as reais necessidades das partes interessadas
para a definio correta e completa dos requisitos do produto e do projeto.
Mas, afinal, o que so mesmo os REQUISITOS?
Requisitos so as caractersticas, funcionalidades e outras peculiaridades que as partes inte-
ressadas desejam no produto e no projeto.
Os requisitos do produto podem ser na forma de atributos (dimenses, por exemplo) ou de
capacidade (performance e funcionalidade). Tambm temos os requisitos do projeto, que se rela-
cionam com o modo de execuo do trabalho (os sistemas de segurana no podem ser desliga-
dos durante a atualizao, por exemplo).

Mr. PROJECT
Requisitos representam necessidades quantificadas, documentadas e priorizadas das par-
tes interessadas e podem ser:
requisitos funcionais: diretamente relacionados ao produto (design, dimenses, es-
pecificaes, caractersticas externas);
requisitos no funcionais: indiretamente descritos (segurana, performance, confia-
bilidade.
Algumas Ferramentas e Tcnicas propostas no Guia PMBOK:
Entrevistas;
Dinmicas de Grupo;
 Oficinas;
Tcnicas de Criatividade em Grupo: Brainstorming, Tcnica do Grupo Nominal, Tc-
nica Delphi, Mapas Mentais, Diagrama de Afinidade;
Tcnicas de Tomada de Deciso em Grupo;
Questionrios e Pesquisas;
Observaes (investigao in loco);
Prottipos maquetes, modelos e produtos preliminares elaborados progressiva-
mente.

6.2.2 Documentando os requisitos do projeto

A documentao dos requisitos do projeto deve descrever e priorizar como os requisitos in-
dividuais atendem aos objetivos do projeto.
Os requisitos devem ser claros, evitando ambiguidade e incerteza, investigveis e mensur-
veis, completos, consistentes e acordados (aceitos) pelas partes interessadas.
Um documento de requisitos ser to mais complexo quanto maior a complexidade do pro-
jeto. Pode ser uma simples lista de requisitos ou ento podem ser necessrios diversos documen-
tos e um sistema de gesto da configurao, como seria o caso do nosso projeto exemplo AllMar-
VANT. Porm, para fins didticos e de simplificao, eu vou resumir esses requisitos naqueles
mais importantes, hipoteticamente.
Podemos fazer a Matriz de Rastreabilidade de Requisitos usando o MS-Excel para o nosso
planejamento inicial. Posteriormente, podemos escrever e detalhar o nosso Plano de Gerencia-
mento do Projeto com maiores informaes. Lembre-se de que o projeto como um organismo
vivo em evoluo. No se preocupe em ter requisitos e escopo completo logo na primeira semana
do projeto. Esses aspectos importantssimos sero mais detalhados medida que formos conhe-
cendo melhor as necessidades do projeto, coletando os requisitos, e tambm teremos outras
ideias quando comearmos a pensar em como executar o projeto, o que ser feito quando esti-
vermos definindo as atividades ou tarefas. medida que comearmos a delinear as necessidades
de recursos, podemos encontrar outras restries que iro impactar no nosso projeto e requerer
modificaes.
Voltando nossa Matriz de Rastreabilidade de Requisitos, ela faz parte de um documento de
requisitos que deve incluir:
necessidade do negcio ou oportunidade;
 objetivos do negcio e do projeto para permitir rastreamento;
requisitos funcionais;
requisitos no funcionais;
requisitos de qualidade;
critrios de aceitao;
impactos em outras reas e negcios;
requisitos de suporte e treinamento;
premissas e restries dos requisitos.

Tabela 6.1 Exemplos de objetivos e necessidades do projeto.

Objetivo Entrega Critrio de Sucesso

Padres de economia
Sistema de Propulso
Autonomia 12 h contnuas de voo

Capacidade de Combustvel 12 h contnuas de voo

Sistema Inercial

Georreferenciamento GPS Erro menor que X%

SIG

WI-FI criptografada
Imagem em Tempo Real Sistema de Comunicao
Largura de banda

Projeto Aerodinmico Padres XYZ

Aeronavegabilidade
Sistema de Navegao Padres XYZ
 A matriz de rastreabilidade de requisitos deve conectar os requisitos (necessidades) s es-
pecificaes (como o produto ou servio ir satisfazer as necessidades). importante que consi-
gamos ter uma viso geral dos requisitos e seu interrelacionamento, alm de referncias quanto
aos documentos que justificam essas necessidades para as especificaes. Vamos dar uma olhada
na matriz a seguir, como exemplo.

Tabela 6.2 Matriz de rastreabilidade de requisitos (exemplo).

Priori-
ID Requisito Descrio Tipo
dade

Padres de O projeto deve seguir o PMBOK e documenta- No funci-

1 1
Projeto o aplicvel, incluindo a ISO 14.857 onal

Padres de O produto deve atender legislao aeronu-

2 Funcional 1
Produto tica e normatizao aplicvel

O produto deve atender aos requisitos para

3 Certificao Funcional 1
certificao e homologao

No funci-
4 Custo Uso Design to Cost 2
onal

5 Escabilidade Modularizao do produto Funcional 2

Como mencionamos nos captulos iniciais, o planejamento um processo de descoberta

do que queremos fazer e de como pretendemos fazer. Isto , o detalhamento e a definio do
produto e do projeto vo ocorrendo aos poucos na fase de planejamento. Na medida em que
tivermos maior conhecimento do projeto, requisitos mais completos e bem definidos, j est a-
remos tambm consolidando o escopo atravs da linha de base de escopo (composta pela De-
clarao de Escopo do Projeto, Estrutura Analtica do Projeto EAP e Dicionrio da EAP). Po-
demos incluir outras colunas na Matriz de Requisitos para acompanhar o status dos requisitos,
seu interrelacionamento e tambm quais pacotes de trabalho da EAP esto envolvidos nesses
requisitos. Pode inclusive ser necessrio o uso de um software para gerenciamento de configu-
rao, como o caso em projetos aeronuticos.
Mr. PROJECT
Os projetos de produtos complexos, como os projetos aeronuticos, necessitam de um
grande apoio de engenharia de sistemas e requisitos, sendo que existem padres impor-
tantes nessas reas, alm da teoria e bibliografia envolvidas.
Sugerimos BLANCHARD, Systems Engineering and Analysis 5. ed., 2010, um livro excelente
sobre o assunto. Tambm existe o Systems Engineering Body of Knowledge, elaborado pelo
International Council of Systems Engineering (INCOSE). Outra referncia importante, em
projetos de engenharia, Requirements Engineering, 3. ed. (HULL, 2010).
Colocamos a Figura 6.1 para ilustrar o gerenciamento dos requisitos associado engenha-
ria de sistemas e gerenciamento da configurao.

Figura 6.3 Engenharia de requisitos.

Em engenharia de software, utiliza-se bastante o Rational Unified Process (RUP), dividido

em quatro fases que englobam as disciplinas necessrias execuo do projeto e constru-
o do produto, conforme a Figura 6.2.
 Fonte: Disponvel em: <www.ibm.com/developerswork/rational/library/4763.htm>.
Figura 6.4 Processo unificado racional.

6.2.3 Escopo e Plano Preliminares de Projeto

Em projetos de grande porte e complexidade, o planejamento pode ser dividido em fases,

devido ao esforo e trabalho envolvido. No caso do nosso projeto-exemplo, o desenvolvimento de
um Veculo Areo No Tripulado (VANT), o planejamento demanda tempo e envolvimento de v-
rios especialistas.
Conforme orientao do Guia PMBOK, o projeto realizado de forma incremental e itera-
tiva. Isto , medida que vamos nos aprofundando e conhecendo mais sobre o projeto, podemos
detalhar seu planejamento, o que tambm pode demandar revises em documentos e planos an-
teriores para manter a coerncia e atualizao.
Em nosso caso, vamos fazer um Plano Preliminar de Projeto, contendo o escopo preliminar
e as diretrizes bsicas de gerenciamento, bem sucinto antes de partir para a Declarao de Escopo
do Projeto.
Nosso plano preliminar tambm ir conter os requisitos iniciais, que sero refinados na de-
clarao do escopo e na matriz de rastreabilidade dos requisitos do projeto, a serem desenvolvi-
das no prximo item.
O plano preliminar deve contar informaes sobre:
 Identificao do Projeto;
Objetivo do Projeto;
Escopo Preliminar;
Excluses de Escopo;
Requisitos do Projeto;
Sumrio Executivo (cronograma bsico de marcos);
Necessidades de Recursos (humanos, financeiros e materiais).

A seguir, temos um exemplo de plano preliminar de projeto.

PLANO PRELIMINAR DE PROJETO

NOME DO PROJETO

Controle de Verso

Verso Data Autor

1.0 13/6/2014 Mrio Henrique Trentim Gerente do Projeto

Informaes Bsicas

Nome do Projeto AllMar-VANT

Solicitante Gerente do Programa AllControl

Cliente Diviso de Aeronutica

Data da Solicitao 13/6/2014

Gerente do Projeto Mrio Henrique Trentim

1. Resumo do Projeto

Introduo e Justificativa
Descrio da situao que gerou a necessidade do projeto, o motivo pelo qual ele foi iniciado, ex-
pectativas para com os resultados do projeto e possveis solues.
Descrio do produto ou servio do projeto soluo para o problema contextualizado acima.
Ressaltar alinhamento estratgico do projeto e justificativa empresarial (o que a empresa vai ga-
nhar executando o projeto).

2. Objetivo do Projeto

Descrio do que se espera atingir com a implementao do projeto, seu produto, ou servio.
Fatores de sucesso e critrios de xito.

3. Escopo Preliminar do Projeto

Descrio do escopo do projeto, determinando o que faz parte do mesmo e o que no ser entre-
gue/feito no projeto.
Descrio preliminar dos requisitos e expectativas do cliente, patrocinador e stakeholders escopo
do produto, conforme levantamento das necessidades do cliente.

4. Principais Fases e Entregas

Descrio das principais entregas e ciclo de vida do projeto.

5. Estimativas Iniciais de Recursos

Financeiros

Estimativa de custo do projeto.

Humanos

Estimativas de pessoal necessrio para realizar o trabalho esperado para o sucesso do projeto.

Materiais

Estimativas sobre os materiais, aquisies necessrias para o desenvolvimento do projeto.

6. Cronograma Bsico do Projeto

Descrever MARCOS principais estimados.

Indicaes de incio e trmino, ideias para o projeto, bem como estimativas de entrega dos produ-
tos finais e intermedirio do mesmo.

7. Premissas, Restries e Riscos

Premissas

Restries
 Riscos Identificados

8. Anlise Financeira Estudo de Viabilidade

Descrio dos custos estimados e do retorno esperado do projeto, incluindo estudo de viabilidade.

9. Planejamento de Comunicao

Descrio de como as informaes geradas pelo projeto sero distribudas e armazenadas,

bem como que ordem hierrquica ser utilizada para o trfego de dados.

10. Gerenciamento de Mudanas

Descrio de como as mudanas devem ser requisitadas, aprovadas e implementadas.

Desejvel incluir Funes e Responsabilidades dos stakeholders.

6.3 Declarao de Escopo do Projeto

A chamada linha de base de Escopo composta por: Declarao de Escopo do Projeto, Estru-
tura Analtica do Projeto (EAP) e Dicionrio da EAP.
A partir da Declarao Preliminar de Escopo e dos Requisitos do Projeto, podemos elaborar
a Declarao de Escopo do Projeto, documento definitivo que serve de base para o restante do
planejamento do projeto.
 Usualmente, a Declarao de Escopo do Projeto um documento que contm uma descrio
das entregas do projeto e de seus requisitos. Com base na Declarao de Escopo, podemos elabo-
rar a Estrutura Analtica do Projeto, que uma representao hierrquica do projeto orientada a
entregas.
A Declarao do Escopo, portanto, define e descreve quais resultados tangveis, entregas, o
projeto deve produzir e quais resultados ele deve atingir. A EAP nos mostrar essas entregas e
resultados de forma hierarquizada, isto , as entregas menores, componentes e entregas parciais,
iro formar as entregas maiores em nveis superiores, tais como subsistemas e sistemas, at ter-
mos todos os objetivos do projeto atingidos.
O Plano Preliminar de Projeto, que criamos no item anterior, contm vrias informaes que
constituem a Declarao de Escopo do Projeto, sendo um documento que pode ser redundante. A
diferena que o Plano Preliminar de Projeto feito a partir das informaes iniciais, por isso,
preliminar. Quando estivermos redigindo a Declarao de Escopo do Projeto, precisamos ter
maior nvel de conhecimento sobre o projeto e de certeza sobre os resultados esperados, requi-
sitos e as entregas a serem produzidas. A Declarao do Escopo deve ser o mais completa possvel,
uma vez que ela ser a base para os demais planos subsidirios que compem o Plano de Geren-
ciamento de Projeto, que o documento norteador da execuo.
A seguir, temos a nossa Declarao de Escopo do Projeto.
DECLARAO DE ESCOPO DO PROJETO
NOME DO PROJETO

Controle de Verso
Verso Data Autor Notas de Reviso
1.0 13/6/2014 Mrio Henrique Trentim

Informaes Bsicas
Nome do Projeto AllMar-VANT
Solicitante Diretor do Escritrio de Projetos
Cliente Diviso de Engenharia Aeronutica
Data da Solicitao 13/6/2014
Gerente do Projeto Mrio Henrique Trentim
1. Resumo do Projeto

O projeto AllMar-VANT tem como principal entregar um Veculo Areo No Tripulado para fins de
imageamento e vigilncia. Ter aplicao em reas de mapeamento e georreferenciamento, alm
de poder ser utilizado para a vigilncia e segurana em reas abertas.

2. Objetivo do Projeto

Desenvolver um Veculo Areo No Tripulado para aplicaes em imageamento, vigilncia e segu-

rana. O VANT a ser desenvolvido deve atender os requisitos gerais descritos a seguir:
Autonomia de 18 h;
Teto Operacional de 15000 ft;
Carga Paga de 120 kg;
Alcance de 200 km.

3. Metas do Projeto

Documentao
Plataforma de Voo
Sensores de Misso
Estao Terrestre
Sistemas e Interfaces
Software
Sistema de Controle
Sistema VANT
Certificao e Aceitao
4. Lista Completa de Entregas e Requisitos

Documentao:
Coleta de Requisitos;
Definio de Escopo;
Plano de Projeto;
Relatrios e Documentos para Certificao.
Plataforma de Voo:
Aeronutica;
Avinica.
Aquisio de Sensores de Misso:
Imageamento.
Aquisio da Estao Terrestre:
Controle remoto.
Sistemas e Interfaces:
Engenharia de Sistemas.
Software:
Comunicao;
Visualizao;
Navegao;
Mapa Mvel;
Vigilncia.
Sistema de Controle:
Modo Autnomo;
Piloto Automtico;
Pouso e Decolagem.
Sistema VANT:
Integrao;
Prottipo e Testes em Solo;
Ensaios em Voo;
Plataforma Definitiva.
Certificao e Aceitao:
 Controle de Qualidade;
Reviso de Requisitos;
Testes Finais e Homologao.

5. Excluso de Escopo

No faz parte desse projeto o desenvolvimento de sensores de misso e imageamento, interfaces

EO/ IR e SAR, que sero adquiridos e integrados ao sistema.
Tambm no faz parte desse projeto o desenvolvimento da Estao Terrestre, que ser adquirida
e integrada aos demais sistemas do projeto.

6. Estimativas de Tempo e Custo

Durao estimada de 48 meses e Custo estimado de R$ 12 milhes.

7. Funes e Responsabilidades

Levantamento Planeja-
Cargo Execuo Avaliao Encerramento
de Informaes mento

Patrocinador V V I I I

Gerente de Projeto T T V V V

Gerente de Tecnologia
V I I
e Mercado

Equipe de Engenharia E I I
 Coordenador Jurdico V I

T Toma Desciso

E Execulta

V Valida

I informado

8. Premissas, Restries e Riscos

Premissas

Sero utilizados os conhecimentos desenvolvidos no Projeto FINEP VANT CT-AERO como ponto
de partida nas definies de Plataforma de Voo, Sistema de Navegao e Controle (SNC) e Estao
de Solo (E-Solo).
Utilizaremos fornecedores de subsistemas do VANT e dos sensores de misso (EO/IR, SAR e outros).

Restries

Oramento fixo.
Equipe de Engenharia e Pesquisa limitada.

Riscos Identificados

Dificuldade nas definies de Engenharia de Sistemas do VANT;

Possveis problemas de Integrao e Interfaces;
Necessidade de fornecedores qualificados e capacitados;
 Exigncia de certificao e homologao do VANT.

9. Critrios de Aceitao do Produto/Servio

O critrio de aceitao final a homologao e certificao do VANT, passando por todos os testes
pertinentes. Os requisitos iniciais devem ser obedecidos:
Autonomia de 18 h;
Teto Operacional de 15000 ft;
Carga Paga de 120 kg;
Alcance de 200 km.

Assinatura do Patrocinador: Data:

Assinatura do Gerente do Projeto: Data:

Assinatura da Alta Administrao: Data:

 Mr. PROJECT

Para uma viso melhor do projeto VANT, recomendamos visitar os links abaixo. L esto apre-
sentaes sobre VANT e o seu contexto, reforando as referncias que mencionamos anterior-
mente.
Veculos No Tripulados, tanto areos quanto terrestres ou aquticos, possuem uma gama
variada de aplicaes, tais como: pesquisa submarina, vigilncia, segurana, controle de
queimadas, imageamento e mapeamento, apoio em reas de difcil acesso e mais. Obvia-
mente, tambm existem muitas aplicaes estratgicas de Defesa, o que motivou o incio
dessas pesquisas no Estados Unidos, principalmente.

<http://www.iae.cta.br/noticias/17062010_Projeto_VANT_concluido_junho.php>
<https://www.defesa.gov.br/arquivos/pdf/ciencia_tecnologia/7_semina-
rioC_T/7_quarta/DCTA.pdf>
<https://www.defesa.gov.br/arquivos/pdf/ciencia_tecnologia/7_semina-
rioC_T/7_quarta/VANT.pdf>
<http://www.dcabr.org.br/download/eventos/eventos-realizados/2010/semina-
rio-vant-27-10-2010/apr/10_Desenvolvimento%20tecnologico_Flavio%20Araripe.pdf>
<http://www.brvant.com.br>

6.4 Estrutura Analtica do Projeto e Dicionrio

Vimos que a Declaraca o do Escopo do Projeto, portanto, descreve detalhadamente as entregas do
projeto e o trabalho necessa rio para criar as mesmas. Isto , esse documento define o que faz parte do
projeto e o que na o faz parte do projeto (escopo e na o escopo).
Trata-se de um documento essencial para obter entendimento comum do escopo entre as
partes interessadas e auxiliar no gerenciamento das expectativas. Porm, a Declarao de Escopo
do Projeto tem uma desvantagem do ponto de vista de comunicao porque ela pode ser bastante
extensa e de difcil leitura devido aos detalhes das entregas e requisitos. a que entra a Estrutura
Analtica do Projeto, uma representao grfica do projeto orientada s entregas e pacotes de
trabalho de uma maneira hierarquizada.
Ou seja, a EAP contm todo o trabalho do projeto para produzir todas as suas entregas desde
os nveis mais baixos at serem consolidadas e integradas para formar o produto final e atingir o
objetivo do projeto. Trata-se, portanto, de uma excelente ferramenta de comunicao e planeja-
mento tanto para a equipe do projeto quanto para os demais stakeholders.
A EAP deve ser detalhada e completa o suficiente para evitar scope creep, que o crescimento
desordenado do escopo ou alteraes frequentes. A vantagem de quebrar o produto final em sis-
temas e subsistemas at o nvel de componentes que teremos entregas parciais e objetivos de
curto prazo para o projeto, o que facilita o trabalho e tambm o controle. possvel medir o an-
damento do projeto em incrementos menores para atingir marcos importantes do projeto.
O Dicionrio da EAP traz uma descrio mais detalhada dos pacotes de trabalho e das entre-
gas, sendo uma boa prtica definir os critrios de sucesso juntamente com os requisitos e especi-
ficaes para que possamos determinar a concluso ou no de um pacote de trabalho ou entrega.
Vale relembrar que a Declarao de Escopo do Projeto, que d origem EAP, define os limites
do projeto (o que ser feito e o que no ser feito escopo e suas excluses).
Ns j fizemos nossa Declarao de Escopo do Projeto anteriormente. Embora ela no esteja
completa e detalhada o suficiente, serve aos nossos propsitos didticos para a utilizao do MS-
Project 2013.
A seguir, alguns exemplos de Estrutura Analtica de Projeto (EAP) na Figura 6.5.

Figura 6.5 Exemplos de EAP.

 Vamos agora organizar nossa Estrutura Analtica do Projeto a partir da Declarao de Escopo
do Projeto que criamos anteriormente.
Figura 6.6 Estrutura analtica do projeto-exemplo (mais detalhada).

Na Figura 6.6, temos uma EAP mais detalhada para o projeto-exemplo apresentado anteri-
ormente. No podemos considerar que esteja totalmente completa, mas serve aos nossos prop-
sitos didticos, como j mencionei. Lembre-se de que possvel atualizar a EAP (e todos os outros
documentos) com correes, novas informaes e maior detalhamento ao longo do planejamento
do projeto. Quando estivermos na Execuo do projeto, ainda assim podemos atualizar os docu-
mentos de projeto, agora passando pelo processo de Controle Integrado de Mudanas.
Salientamos tambm que a criao e as atualizaco es dos Documentos do Projeto (Registro
de Stakeholders, Documentos de Requisitos, Matriz de Rastreabilidade, Termo de Abertura e De-
clarao de Escopo do Projeto, alm de outros documentos e planos) devem ser preferencial-
mente acordadas e aprovadas pelas partes interessadas. Em princpio, todas as partes interessa-
das devem ter acesso a uma co pia desses documentos, ressalvando a necessidade de sigilo even-
tual.
A Declarao do Escopo do Projeto, juntamente com a Estrutura Analtica do Projeto e o Dicio-
nrio da EAP, formam a linha de base de escopo do projeto, que ir nortear o restante do planeja-
mento e a execuo do projeto. Essa linha de base serve tambm para avaliar solicitaco es de mu-
danca ou trabalho adicional, permitindo analisar o que escopo e no escopo, bem como avaliar os
impactos das mudanas de forma sistmica no projeto.

Mr. PROJECT
Requisitos so as bases de construo do produto e da gesto do projeto. Esses pontos
de formaca o precisam atender s necessidades dos stakeholders, o que implica a coleta
e anlise de requisitos. Esses requisitos devem ser analisados para que se proponham
solues e sejam geradas as especificaes decorrentes.
Para isso, em certo momento do planejamento, os requisitos precisam ser congela-
dos. Nesse ponto teremos nossa matriz de requisitos e a Estrutura Analtica do Pro-
jeto, bem como a linha de base de Escopo, delineadas.
6.5 Entregas e Fases no MS-Project

A Estrutura Analtica do Projeto, como mencionamos, uma diviso hierarquizada orientada

s entregas do projeto. Isto , a EAP est relacionada com as entregas (resultados). Porm, para
produzir essas entregas, e completar o escopo do projeto, so necessrias as atividades (trabalho)
do projeto, como veremos no Captulo 7.

Por enquanto, vamos apenas transferir a EAP criada no item anterior para o formato do MS-
Project 2013, iniciando com isso as nossas estimativas de atividades e recursos, que posterior-
mente sero refinadas e detalhadas at que tenhamos nosso cronograma e oramento finais para
compor o Plano de Gerenciamento do Projeto.
A ttulo de curiosidade, a EAP foi criada usando o software WBS Chart Pro, Critical Tools, que
se integra ao MS-Project 2013. Com essa ferramenta, possvel alternar entre a viso da EAP
(WBS Chart Pro) e a viso do cronograma (MS-Project) com atualizao bidirecional, isto , as
mudanas feitas no MS-Project se refletem no WBS Chart Pro e vice-versa. uma ferramenta bas-
tante til. A seguir, temos a viso em termos de cronograma, transferindo essa EAP para o MS-
Project. Vale notar que ainda no inserimos as duraes nem o detalhamento das fases, pacotes
de trabalho e atividades, que ainda vo ser inseridas e sero assunto do nosso Captulo 7.
Devido ao grande nmero de linhas, as figuras podem ser de difcil leitura. Por isso, coloca-
mos trs figuras com diferentes nveis de detalhamento do projeto, a partir do que temos agora
em nossa EAP.
Com isso d para ter uma ideia de quo complexo pode ficar o planejamento do projeto, do
ponto de vista de seu cronograma, como estamos vendo agora. Podemos ter projetos em milhares
de linhas, cada uma correspondendo a uma atividade, entrega ou fases diferentes.
Figura 6.7 EAP no MS-Project para o projeto-exemplo (atividades-resumo).

Uma das grandes vantagens do MS-Project, como veremos, que ele nos permite inserir e
modificar tarefas, bem como suas atribuies, detalhamento, definies e recursos, de forma fcil
e rpida.
Alm disso, o MS-Project permite diferentes modos de visualizao, como mencionamos nos
captulos iniciais, e tambm possui diversos formatos de relatrios, o que facilita o entendimento
do projeto, comunicao com as partes interessadas, acompanhamento e controle, replaneja-
mento e modificaes, entre outros recursos interessantes.
Vamos em frente!