gerenciamento de projetos com Ênfase...
TRANSCRIPT
Instituto de Educação TecnológicaCarlos Fernando Vasconcellos Ribeiro Cavalcanti Albuquerque
Carlos Henrique LoyolaMarlene Maria Francisco de Oliveira
Rogério Márcio GalantineSergio Luiz Gomes Santiago
GERENCIAMENTO DE ESCOPO COM ÊNFASE EM GESTÃO DE PLEITOS
Belo Horizonte, MGMaio/2013
2
Carlos Fernando Vasconcellos Ribeiro Cavalcanti AlbuquerqueCarlos Henrique Loyola
Marlene Maria Francisco de OliveiraRogério Márcio Galantine
Sergio Luiz Gomes Santiago
GERENCIAMENTO DE ESCOPO COM ÊNFASE EM GESTÃO DE PLEITOS
Trabalho de conclusão de especialização apresentado ao Curso de Gestão
Avançada de Projetos do IETEC como requisito parcial à obtenção do título de
especialista em Gestão de Projetos
Orientador: João Carlos Araújo da Silva Neto
Belo Horizonte, MGMaio/2013
3
ONDE ESTÃO A LISTA DE FIGURAS, A LISTA DE ABREVIATURAS?????
4
RESUMO
O gerenciamento de escopo é a atividade que pode resultar nas melhores chances
de sucesso em um projeto, para tanto, todo um trabalho de levantamento de
requisitos, premissas, restrições e exclusões, elaborado de forma sistêmica e
precisa deve representar as expectativas do cliente quanto ao produto final. O
resultado do trabalho inicial desta atividade deve ser registrado num Termo de
Abertura do Projeto – TAP, que será o alicerce do projeto, devendo ter-se como
objetivo a blindagem deste de forma a se evitar que solicitações de mudanças
possam vir a descaracterizar o objeto. Quando a equipe de projeto passa a obter
mais dados, o passo seguinte é explorar os detalhes e firmar conceitos, traduz-se
numa Declaração de Escopo que deve ser clara, objetiva, contudo concisa, onde os
objetivos necessariamente devem estar perfeitamente delineados, juntamente com
os requisitos, as premissas, as restrições, as exclusões e os critérios de aceitação
do projeto. Este trabalho é um estudo da elaboração de um escopo bem definido,
que permita a melhor condução de um projeto, minimizando as ocorrências de
mudanças e, por conseguinte, de pleitos. Dessa forma, o dispêndio de esforço para
se estruturar, documentar, aprovar, divulgar e controlar o escopo deve ser o maior
possível, caso contrário, os esforços para ajuste do descontrole das metas de
entregas do produto dentro das especificações, dos custos, da qualidade, dos
prazos, poderá ter um impacto muito superior e negativo no projeto, situação que
poderá torná-lo inviável.
Palavras-chaves: Gerenciamento de escopo, Declaração de Escopo,
Monitoramento e Controle de Escopo e Pleitos.
5
ABSTRACT
Scope management is the activity that can result in the best chances of success on a
project, to do so, a whole work of gathering requirements, assumptions, limitations
and exclusions, elaborate systemically and needs must represent the client's
expectations as to the final product. The result of the initial work of this activity should
be registered on a Project Chapter - PC, that will be the foundation of the project and
should have as objective the armor of this in order to prevent requests for changes
could discharacterize the object. When the project team starts to get more data, The
next step is explore the details and establish concepts translates in a Scope
statement which must be clear, concise, objective, where the goals necessarily must
be perfectly outlined, together with the requirements, assumptions, limitations,
exclusions and the acceptance criteria of the project. This work is a study of the
development of a well-defined scope, allowing the best driving a project, minimizing
the occurrence of changes and, consequently, of pleas. In this way, the expenditure
of effort to design, document, approve, publish and control the scope must be the
highest possible, otherwise the efforts for lack of product deliveries within
specifications, costs, quality, deadlines, you may have a much greater impact and
negative in the project, situation which may make it impractical.
Keywords: Scope Management, scope Declaration and applications.
6
SUMÁRIO
1 INTRODUÇÃO......................................................................................................6
2 REFERENCIAL TEÓRICO....................................................................................9
3 SOLUÇÕES PROPOSTAS.................................................................................10
4 PLANO DE PROJETO DE IMPLANTAÇÃO........................................................11
5 CONCLUSÕES E RECOMENDAÇÕES.............................................................12
6 REFERÊNCIAS BIBLIOGRÁFICAS....................................................................13
7
1 INTRODUÇÃO
O gerenciamento de projetos propõe processos e boas práticas que devem se
traduzir na maximização do aproveitamento da energia dispendida em cada projeto,
assim, o conjunto de boas práticas preconizado pelo Project Management Institute -
PMI e por outros órgãos assemelhados, visa difundir metodologias que, bem
aplicadas, promovam a garantia das entregas do objeto dentro dos parâmetros
definidos.
Dentro do roteiro de boas práticas, numa sequência lógica de desenvolvimento dos
projetos, está a definição do escopo do que se pretende entregar/receber. A
definição preliminar de escopo de um projeto é o resultado da análise de negócio
procedido, ou seja, a ideia estruturada do que fazer deve ser grafada no Termo de
Abertura do Projeto – TAP (Project Charter).
Conforme definido na NBR: ISO 10.006, Projeto é um processo único, consistindo de
um grupo de atividades coordenadas e controladas com datas para início e término,
empreendido para alcance de um objetivo conforme requisitos específicos, incluindo
limitações de tempo, custo e recursos.
Diante da definição de projeto e dos ditames agregados, é perfeitamente dedutível
que a definição de escopo é a principal atividade que influenciará no sucesso deste.
Segundo o PMBOK, 4ª Edição (2009), o TAC (4.1) é definido no grupo de processos
de Iniciação, seguido da Identificação das Partes Interessadas ou Stakeholders
(10.1). Na sequência, devem ser executados os processos de planejamento relativos
ao escopo – Coletar os Requisitos (5.1), Definir o Escopo (5.2) e Criar a EAP –
Estrutura Analítica do Projeto (5.3). (PMBOK, 2009)
Da literatura especializada fica tácita a necessidade do emprego do maior esforço
possível para que os processos relativos à coleta e definição do escopo e a criação
da EAP são os pilares de sustentação para se atingir o sucesso do projeto.Definir o Escopo do Projeto é uma etapa de vital importância. Se não for feita da forma correta, o projeto estará fadado ao fracasso, uma vez que é o escopo que determina o que irá (e não irá) ser feito/produzido/entregue ao termino do projeto. Um escopo mal estruturado levará inevitavelmente a falhas de cronograma e de orçamento, uma vez que os problemas decorrentes da má especificação se farão presentes e a equipe terá que achar caminhos alternativos para a execução do projeto. Por fim, um escopo mal definido resulta em um cliente insatisfeito, uma vez que o mesmo pediu X e recebeu Z, levando a uma insatisfação do executivo, do time do projeto
8
e do gerente. O efeito cascata disso pode ser terrível, como uma caça às bruxas para determinar de quem foi a culpa, quando na verdade a culpa foi do escopo mal definido (SANTOS, Diego Nei, 2009)
Figura 1 – Grupos de Processos (PMI)
Da Figura 1 – Grupos de Processos (PMI), este trabalho identifica um circuito
fechado entre os grupos de processos Planejamento, Execução e Controle (circulo
vermelho). Este circuito fechado é alimentado de forma primária pelo grupo de
Iniciação, sendo esta alimentação procedida ao grupo Planejamento. A saída do
circuito fechado ocorre quando da verificação do atingimento dos objetivos pelo
grupo de Controle, derivando para o grupo de Encerramento. (PMBOK, 2009)
Destarte, analisando o detalhe do grupo de Planejamento quanto a Escopo –
processos 5.1, 5.2 e 5.3 do PMBOK, 2009 – verifica-se que o escopo, além de ser o
padrão diretivo do “a fazer”, deve ser realimentado pelos processos do Grupo de
Monitoramento e Controle, baseando-se nas aferições das ocorrências do Grupo de
Execução, de modo que haja atualização da Declaração de Escopo / EAP. As
atualizações e otimizados os dados e as diretivas obtenção do Produto devem
ocorrer a cada ciclo de revisão fundamentada e aprovada. Com estas constatações
é possível afirmar que o Gerenciamento do Escopo é fundamental para a
consecução dos objetivos de cada projeto, pois sem esta gestão o projeto poderá
9
derivar para o caos, não atingindo as metas/parâmetros e, até, podendo chegar a
sucumbência, gerando pesados ônus para os patrocinadores.
O trabalho ora apresentado se dispõe a analisar as questões relativas à montagem
de uma Declaração de Escopo que possa realmente ser uma forte diretiva do
projeto, o Controle quanto ao cumprimento do estabelecido na Declaração de
Escopo / EAP e das necessidades de ajustes do Escopo e, derivando dos ajustes,
pleitos que se mostram necessários para ajuste das condições comerciais e técnicas
mais adequadas a consecução do objeto.
A Declaração de Escopo, além de ser uma atividade inicial das mais importantes,
como já explanado, requer um Gerenciamento de Escopo constante de sorte a
manter-se alinhado com as variâncias que normalmente ocorrem ao longo da
duração do projeto. O Gerenciamento de Escopo objetiva garantir a execução do
objeto dentro das condições estabelecidas na Declaração de Escopo / EAP, estando
alinhado com a Gestão de Mudanças. A Gestão de Mudanças trata de ajustes quer
de origem externa – partes interessadas, órgãos de controle e licenciamento, etc. –
ou internas, representadas por demandas derivadas de necessidades diversas de
readequação em função de ocorrências dentro do grupo de processos de Execução,
demandas estas tabuladas e registradas no grupo de Monitoramento e Controle.
Dentro da análise de pleitos, o trabalho apresenta enfoque diferenciado para pleitos
em geral e para o tratamento de reequilíbrio econômico-financeiro de contratos,
matérias que analisadas na superficialidade aparentam ser iguais, contudo, o
regimento jurídico e as condicionantes processuais são bem distintas, assim
necessitando de tratamentos específicos, daí a abordagem diferenciada neste
trabalho. No caso de pleitos em geral, o enfoque trazido à baila é o da Gestão de
Mudanças em função de necessidades de adequações diversas e/ou solicitações de
alterações pelas partes interessadas. No caso de Reequilíbrio Econômico-Financeiro
a ênfase abordada neste trabalho esta nos Contratos Administrativos, maior foco de
embates.
Diante das informações aqui apresentadas, a questão chave é o conjunto de
processos que devem ser demandados para se obter uma gestão de escopo mais
eficiente e eficaz com minimização da quantidade de pleitos.
10
2 REFERENCIAL TEÓRICO
Do Harold Kerzner, Gerenciamento de Projetos - 10ª edição (2011), se extrai do
Capítulo 22 - O "NEGÓCIO" DAS MUDANÇAS NO ESCOPO:22.0 INTRODUÇÃOPouquíssimos projetos são concluídos de acordo com o plano original. As mudanças no plano resultam do aumento do conhecimento, da necessidade de competitividade ou de mudanças no gosto do cliente/consumidor. Depois que as mudanças são feitas, quase sempre há um aumento significativo no orçamento e/ou um alongamento do cronograma.
O processo de recomendação e aprovação das mudanças no escopo pode variar dependendo de o cliente ser ou não interno ou externo à organização. As mudanças de escopo para clientes externos têm sido vistas como uma fonte de lucratividade adicionada sobre os projetos (KERZNER, 2011, p. 583).
Do texto acima é tácita a visão que a manutenção do plano original dos projetos
“pouquíssimo” ocorre até a conclusão destes. Desta forma, o autor discorre, na
literatura citada, as principais causas e efeitos das ocorrências de mudanças durante
o desenrolar da execução dos projetos. Também é citada no texto do capítulo 22
desse livro a questão de projetos que são sequência de outros ou alimenta outros,
assim, a gestão de mudanças nos antecessores deve atentar para os reflexos
internos a si e aos possíveis desdobramentos em relação aos que lhes sucedem,
sendo, tão ou mais complexa quanto mais longa for a cadeia de relacionamentos.
No texto é visível apenas parte da questão de projetos com sucessores, contudo,
questões relacionadas a projetos com relacionamentos laterais, normalmente
integrantes de um mesmo programa ou, em estância mais distante, por exemplo, de
um mesmo portfólio, também podem, ou não, serem afetados pelas mudanças dos
colaterais, sendo necessária a gestão integrada para mitigar possíveis influências
entre projetos.
Da equipe da Dinsmore Associados, na Palestra Mitigando Fracassos em Projetos
de Cézar Meriguetti com a participação de Paul Campbell Dinsmore, Maio/2012, é
possível coletar dados contidos na Figura 2- Causas de Fracassos onde, apesar de
esta ranqueada como a 3ª causa de fracassos de projetos, a mudança de escopo é
responsável por 70% destas ocorrências, contra 76% das falhas de comunicação –
1º lugar no ranking. Destas informações obtidas em 2010, logo recentes, têm-se a
magnitude do que representam as mudanças de escopo quanto à sucumbência de
projetos.
11
Figura 2- Causas de Fracassos
O PMBOK, 4ª Edição (2009), traz os processos que são considerados os de
melhores práticas para a obtenção de uma Definição de Escopo bem estruturada e
capaz de alicerçar o desenvolvimento do projeto, agregando valor as garantias de
atendimento aos requisitos estipulados.
Dentre os processos delineados na sequencia, em parte já aposta no capítulo 1
INTRODUÇÃO, estão definidos o que deve ser executado e a sequência de
execução, enfim, um delineamento completo para que se atinjam os objetivos
quanto uma Definição de Escopo bem estruturada e completa.
Na Seção 3 - As áreas de conhecimento em gerenciamento de projetos, do PMBOK, 4ª
Edição (2009), onde estão definidos os processos de gerenciamento de projetos e
onde também são definidas as entradas, as ferramentas e técnicas e as saídas de
cada área de conhecimento, estas distribuídas em 9 capítulos. Nesta Seção, o
Capítulo 4, Gerenciamento de integração do projeto, define os processos e as
atividades que integram os diversos elementos do gerenciamento de projetos, onde
estão inclusos os seguintes processos: (PMBOK, 2009, p. 71)
4.1 - Desenvolver o termo de abertura do projeto;
4.2 - Desenvolver o plano de gerenciamento do projeto;
4.3 - Orientar e gerenciar a execução do projeto;
4.4 - Monitorar e controlar o trabalho do projeto;
4.5 - Realizar o controle integrado de mudanças;
4.6 - Encerrar o projeto ou a fase.
12
Dos processos que compõem o Capítulo 4, são estudados neste trabalho o processo
1 e o processo 5 acima listados, respectivamente, Termo de abertura do projeto e
Controle Integrado de Mudanças. Estes dois processos estruturam a base
conceitual do objeto do projeto e se integram de forma a manterem-na sempre
atualizada. Uma base conceitual consistente e atualizada é a melhor garantia de rota
para que o produto a ser entregue o seja nas condições primárias de aceitação.
Também é o norte que indica ao gestor do projeto, fruto dos processos de
monitoramento e controle de mudanças, que o projeto não está sofrendo alterações
que o descaracterize e, quiçá, o inviabilize. Via de regra, é praxe e seguro que o
Gerente de Projeto e todas as partes interessadas tenham o objetivo de garantir que
o TAC seja suficientemente amplo e claro para não necessitar ser modificado caso o
projeto venha a sofrer alterações, garantindo a essência do objeto do projeto.
Mudanças no TAC (Project Charter) levam ao questionamento de o projeto deve
continuar ao ser encerrado e aberto novo projeto.
Ainda navegando pelo PMBOK, 4ª Edição (2009), o Capítulo 5 - Gerenciamento do escopo do projeto descreve os processos relativos à garantia de que o projeto
inclua todo o trabalho necessário, e apenas o trabalho necessário, para que seja
terminado com sucesso. (PMBOK, 2009, p. 103)
Este capítulo inclui:
5.1 - Coletar requisitos;5.2 - Definir o escopo;5.3 - Criar EAP;
5.4 - Verificar o escopo;5.5 - Controlar o escopo.
Dos três primeiros processos acima listados obtém-se a definição do Escopo do
objeto a ser entregue pelo projeto, em especial, a Declaração do Escopo e a
representação gráfica desta – EAP do Projeto, principais documento diretivos do
projeto. Os dois últimos processos acima listados são parte integrante da Gestão de
Escopo, processos estes que fazem parte do Grupo de Monitoramento e Controle e
que ocorrem concomitantemente com o Grupo de Execução.
O contido no item 1.4.2 Gerenciamento de programas do PMBOK, 4ª Edição (2009)
é um alerta importante para as questões de Gerenciamento de Escopo em função
da gestão de mudanças, devendo ser observado que: (PMBOK, 2009, p. 10)O gerenciamento de programas se concentra nas interdependências do projeto e ajuda a determinar a melhor abordagem para gerenciá-los. As ações relacionadas a essas interdependências podem incluir:
13
Solução de restrições e/ou conflitos de recursos que possam afetar múltiplos projetos no sistema;
Alinhamento da orientação estratégica/organizacional que afeta as metas e objetivos do projeto e do programa e;
Solução de problemas e gerenciamento de mudanças em uma estrutura de governança compartilhada (grifo nosso).
Do item 2.1.1 Características do ciclo de vida do projeto do PMBOK, 4ª edição
(2009), verifica-se que a estrutura genérica do ciclo de vida geralmente apresenta as
seguintes características: (PMBOK, 2009, p. 16 e 17) Os níveis de custo e de pessoal são baixos no início, atingem um valor
máximo enquanto o projeto é executado e caem rapidamente conforme o projeto é finalizado.
A linha pontilhada na Figura 2-1 ilustra este padrão típico.
A influência das partes interessadas, os riscos e as incertezas (conforme ilustrado na Figura 2-2) são maiores durante o início do projeto. Estes fatores caem ao longo da vida do mesmo.
A capacidade de influenciar as características finais do produto do projeto, sem impacto significativo sobre os custos, é mais alta no início e torna-se
14
cada vez menor conforme o projeto progride para o seu término. A Figura 2-2 ilustra a ideia de que os custos das mudanças e correções de erros geralmente aumentam significativamente conforme o projeto se aproxima do término. (PMBOK 2009, p. 17)
Do item 2.1.2 Relações entre o ciclo de vida do projeto e do produto, é identificado:Como um produto pode ter muitos projetos associados a ele, é possível obter ganhos de eficiência adicionais gerenciando-se todos os projetos relacionados em conjunto. Por exemplo, uma série de projetos distintos pode ser relacionada ao desenvolvimento de um novo automóvel. Cada projeto pode ser distinto, mas ainda assim contribuir com uma entrega-chave necessária para levar o automóvel ao mercado. A supervisão de todos os projetos por uma autoridade superior pode aumentar significativamente a probabilidade de sucesso. (PMBOK 2009, pág. 18)
15
2.1 DECLARAÇÃO DE ESCOPO
Conforme citado por MICHALICK et al no livro Gestão de Projetos Brasil - Conceitos
e Técnica, IETEC, 2012, para se gerenciar projetos, é recomendado ao gestor
desenvolver alguns processos que o ajudem a ter um escopo bem definido e que
possa ser gerenciado de maneira eficiente.
Do capítulo 5 - Gerenciamento do Escopo, item 5.2 - Definir o escopo (PMBOK,
2009) figura 3, extrai-se que definir o escopo é o processo de desenvolvimento de
uma descrição detalhada do projeto e do produto. “A preparação detalhada da
declaração do escopo é crítica para o sucesso e baseia-se nas entregas principais,
premissas e restrições que são documentadas durante a iniciação do projeto.
Durante o planejamento o escopo é definido e descrito com maior especificidade
conforme as informações a respeito do projeto são conhecidas. (PMBOK, 2009,
p.112).
Figura 3 - Diagrama de fluxo de dados do processo - Definir o escopo
As entradas para o processo de definição do escopo (PMBOK, 2009) são: Termo de
abertura do projeto; Documentação dos requisitos e Ativos de processos
organizacionais. As ferramentas técnicas definidas pelo (PMBOK, 2009) são: Opinião
especializada; Análise do produto; Identificação de alternativas e Oficinas.
16
A definição do termo de abertura do projeto, segundo o (PMBOK, 2009), é
documentar “as necessidades do negócio, o entendimento das necessidades do
cliente, e o novo produto, serviço ou resultado que pretende satisfazer, tais como:
Propósito ou justificativa do projeto; Objetivos mensuráveis do projeto e critérios de
sucesso relacionados; Requisitos de alto nível; Descrição do projeto em alto nível;
Riscos de alto nível; Resumo do cronograma de marcos; Resumo do orçamento”
(PMBOK, 2009, p. 77).
O guia PMBOK (2009) define no item 4.1 - Desenvolver o termo de abertura do
projeto que o Termo de Abertura do Projeto é o documento que formalmente
autoriza um projeto ou uma fase e a documentação dos requisitos iniciais que
satisfaçam as necessidades e expectativas dos Stakeholders. Para o
desenvolvimento do termo de abertura, o PMBOK determina como entradas, a
Declaração do trabalho do projeto; Business case; Contrato; Fatores ambientais da
empresa e Ativos de processos organizacionais. Como ferramentas técnicas tem-se
a opinião especializada e como saída o Termo de abertura do projeto. Abaixo a
figura 4, mostra o diagrama de fluxo de dados.
Figura 4 - Diagrama de fluxo de dados do processo - desenvolver TAP (PMBOK - 2009)
A declaração do trabalho (DT) segundo o PMBOK (2009) é uma descrição
narrativa dos produtos e serviços a serem fornecidos pelo projeto. Sendo que para
projetos internos, a declaração do trabalho é desenvolvida baseada nos requisitos
das necessidades dos negócios, produtos ou serviços e para os externos, ela será
recebida do cliente como parte de um documento de licitação ou como parte de um
contrato. A DT informa:
17
Necessidades de negócios - baseada numa demanda de mercado, avanço
tecnológico, requisito legal ou regulamentação de governo;
Descrição do escopo do produto - documenta as características do produto a
ser criado pelo projeto, bem como a relação entre os produtos e serviços e
necessidade de negócios vinculados ao projeto;
Plano estratégico - documenta os objetivos estratégicos da organização, ao
qual o projeto deverá estar alinhado.
“O Business Case, ou documento semelhante, fornece informações necessárias do
ponto de vista de um negócio, para determinar se o projeto justifica ou não o
investimento” (PMBOK, 2009, p.75). Este é criado em função de diversos fatores:
Demanda de mercado;
Necessidade organizacional;
Solicitação do cliente;
Avanço tecnológico;
Um resíduo legal;
Impactos ecológicos;
Necessidade social (PMBOK, 2009, p. 75 e 76).
O contrato é uma entrada se o projeto estiver sendo realizado por um cliente
externo (PMBOK, 2009, p. 76).
Os fatores ambientais da empresa que podem influenciar o processo de
desenvolvimento do termo de abertura do projeto incluem, mas não estão limitados,
a: Padrões governamentais ou industriais; Infraestrutura organizacional e Condições
do mercado (PMBOK, 2009, p. 76).
Os ativos de processos organizacionais que podem influenciar o processo de
desenvolvimento do termo de abertura do projeto incluem, mas não estão limitados
a: Processos organizacionais padronizados, políticas e definições padronizadas de
processos para uso da organização; Modelos (por exemplo, modelo do termo de
abertura do projeto) e Informações históricas e base de conhecimento de lições
aprendidas (PMBOK, 2009, p. 76).
De acordo com o (PMBOK, 2009) a ferramenta e técnica para apoio na avaliação
das entradas para elaborar o termo de abertura do projeto é a opinião especializada
usada frequentemente para analisar as informações necessárias para desenvolver o
termo de abertura do projeto. Tal opinião e especialidade são aplicadas a qualquer
detalhe técnico.
18
Documentação dos requisitos, item 5.1.3 (PMBOK, 2009), “descreve como os
requisitos individuais atendem às necessidades do negócio para o projeto. Esses
podem começar em um alto nível e progressivamente se tornar mais detalhados
conforme mais detalhes são conhecidos. Antes das linhas de base serem
estabelecidas, os requisitos devem ser não ambíguos (mensuráveis e passiveis de
testes), investigáveis, completos, consistentes e aceitáveis para as principais partes
interessadas.” (PMBOK, 2009, p. 76).
Os ativos de processos organizacionais incluem qualquer um ou todos os ativos
relacionados a processos, de quaisquer ou todas as organizações envolvidas no
projeto que podem ser usados para influenciar o sucesso do projeto. Esses ativos de
processos incluem planos formais e informais, políticas, procedimentos e diretrizes.
Os ativos de processos organizacionais também incluem as bases de conhecimento
das organizações, como lições aprendidas e informações históricas. Eles podem
incluir cronogramas terminados, dados sobre riscos e dados de valor agregado.
Normalmente, a responsabilidade por atualizar e adicionar aos ativos de processos
organizacionais conforme necessário no transcorrer do projeto cabe aos membros
da equipe de projeto. Os ativos de processos organizacionais podem ser agrupados
em duas categorias: Processos e procedimentos e Base de conhecimento
corporativa (PMBOK, 2009, p. 76).
O guia PMBOK (2009), define que declaração do escopo é uma das saídas do item
5.2 - Definição do escopo e uma das entradas do item 5.3 - Criar a EAP e do item
Análise Qualitativa de Riscos. A Declaração do Escopo detalha as entregas do
projeto e o trabalho necessário para se criar estas entregas. Alguns pontos
constantes da declaração do escopo do projeto são fundamentais para o
planejamento e monitoramento do projeto, facilitando a elaboração de um
planejamento mais detalhado, direciona o trabalho da equipe durante a execução,
fornece a linha de base, possibilitando avaliar se as solicitações de mudança ou
trabalho adicional fazem parte do escopo do projeto (PMBOK, 2009).
O nível de eficiência para controlar o escopo pela equipe de projeto poderá ser
avaliado em função do grau e nível de detalhes em que a declaração do escopo
define o trabalho. Deve fornecer um entendimento comum do escopo do projeto
entre os Stakeholders, podendo conter exclusões explícitas do escopo que podem
auxiliar no gerenciamento das expectativas dos Stakeholders. A declaração
19
detalhada inclui, seja diretamente ou por referência a outros documentos, o
seguinte: Declaração do escopo do produto. Elabora progressivamente as
características do produto, serviço ou nos resultados descritos no termo de abertura
do projeto e na documentação dos requisitos. Critérios de aceitação do produto. Define o processo e critérios de aceitação de produtos, serviços ou resultados
concluídos. Entregas do projeto. As entregas incluem tanto as saídas que compõem o
produto ou serviço do projeto, como os resultados auxiliares, tais como relatórios e
documentação de gerenciamento do projeto. As entregas podem ser descritas em
nível conciso ou em grande detalhe. Exclusões do projeto. Identifica de modo geral
o que é excluído do projeto. Declarar explicitamente o que está fora do escopo do
projeto ajuda no gerenciamento das expectativas das partes interessadas.
Restrições do projeto. Lista e descreve as restrições específicas associadas com o
escopo que limitam as opções da equipe, por exemplo, um orçamento pré-definido
ou quaisquer datas impostas ou marcos do cronograma comunicados pelo cliente ou
organização executora. Quando um projeto é feito sob contrato, as cláusulas
contratuais geralmente serão restrições. Informações sobre as restrições podem ser
listadas na declaração do escopo do projeto ou em um registro separado. (PMBOK,
p. 115). Premissas do projeto. Lista e descreve as premissas do projeto
associadas com o escopo e o impacto potencial dessas premissas se forem
provadas falsas. As equipes de projetos frequentemente identificam, documentam e
validam as premissas como parte do seu processo de planejamento. Informações
sobre as premissas podem ser listadas na declaração do escopo do projeto ou em
um registro separado. (PMBOK, p. 116).
Ricardo Vargas define que Declaração do escopo preliminar do projeto ou
Preliminary Project Scope Statement, é a primeira versão da declaração de escopo
do projeto, sendo esta revisada e aperfeiçoada durante os processos de
gerenciamento do escopo do projeto, salientando a existência de apenas uma
declaração de escopo em um projeto. Afirma que entre as declarações preliminar e
final o diferencial está apenas no detalhamento mais apurado na declaração final
que será utilizada para fins de controle e planejamento.
Normalmente a Declaração de Escopo Preliminar do Projeto contém: Título do
Projeto; Nome da pessoa que elaborou o documento; Nome do patrocinador; Nome
do gerente do projeto e suas responsabilidades e autoridades; Organograma
20
preliminar; Nome dos integrantes do time de projeto; Descrição do projeto; Objetivo
do projeto; Justificativa do projeto; Produto do projeto; Expectativa do
cliente/patrocinador; Fatores de sucesso do projeto; Restrições; Premissas; Limites
do projeto e exclusões específicas (tudo o que não será adotado pelo projeto);
Estrutura analítica do projeto (preliminar); Principais atividades e estratégias do
projeto; Principais entregas do projeto; Orçamento básico do projeto; Principais
entregas do projeto; Orçamento básico do projeto; Plano de entregas e marcos do
projeto; Riscos iniciais do projeto; Requisitos de gerenciamento de configuração e
mudanças do projeto; Registro de alterações no documento; Aprovações. (VARGAS,
p. 59).
O resultado, ou saída, primário do processo definir o escopo é a declaração do escopo do projeto. Esse documento na verdade diz "Eis o que faremos neste
projeto" ou "Eis os escopos do projeto e do produto aprovados para este projeto”. O
desenvolvimento da declaração do escopo do projeto pode demorar muito e
envolver a opinião especializada de muitas partes interessadas e até mesmo de
especialistas de fora da organização. Ao definir os requisitos e o escopo, deve-se
identificar as áreas em que as pessoas solicitaram um escopo que não foi aprovado
para entrar no projeto. Também deve ser esclarecida as áreas em que o escopo
poderia facilmente ser incompreendido. É perda de tempo e dinheiro do projeto criar
um escopo que não seja necessário ou aprovado. Ainda assim, isso é fácil de
acontecer. Um truque para evitar esse problema é identificar na declaração do
escopo do projeto o que não está no projeto para deixar claro que tais adições não
são permitidas (MULCAHY, p. 154).
A declaração do escopo do projeto, juntamente com a EAP e o dicionário da EAP,
compõe a linha de base do escopo, que faz parte do plano de gerenciamento do
projeto. A declaração do escopo do projeto pode incluir: Escopo do produto; Escopo
do projeto; Entregas; Critérios de aceitação do produto; O que não faz parte do
projeto; Restrições e premissas (MULCAHY, p. 155).
POSSI et al, no livro Gerenciamento de Projetos - Guia do Profissional -
Fundamentos Técnicos, Vol..3, define para a elaboração do cronograma:
Da declaração do escopo podem-se destacar como informações relevantes as datas compromissadas com terceiros ou com as metas estratégicas da empresa. As restrições mais comuns quando o projeto envolve a contradição de terceiros são:
21
Deve terminar até a data..... Deve iniciar na data.... Não deve começar antes da data....As restrições mais comuns quando o projeto é parte de um contrato são: Deve terminar na data.... Deve iniciar na data....As restrições mais comuns quando o projeto é interno e representa o atingimento de um programa são: Deve terminar até a data.... Deve iniciar a partir da data....Essas ilustrações mostram que na montagem do cronograma do projeto essas informações devem ser levadas em conta, e muitas vezes “amarram” a flexibilidade do planejamento obrigando a equipe a usar de todos os recursos e técnicas disponíveis para atender a essas restrições.Por diversas vezes elementos de controle do projeto são apontados na declaração de escopo obrigando a equipe de projetos a promover a inclusão de marcos refletindo esses elementos. Marcos que não fazem parte integrante do planejamento interno, mas passam a ser necessários para acompanhamento de requisitos dos Stakeholders (Marcus Possi et al, p.107).
XAVIER, no livro Gerenciamento de Projetos - Como definir e controlar o escopo do
projeto define a Declaração do escopo como o anteprojeto do escopo de um projeto.
Ela fornece a documentação que servirá de base para a tomada de decisões e para
a confirmação ou desenvolvimento de um entendimento comum do escopo entre as
partes envolvidas (Stakeholders). Diz ainda que com o progresso do projeto, a
declaração do escopo pode necessitar de revisão para acomodar as mudanças
aprovadas e deve conter, tanto diretamente como por meio de referência a outros
documentos, os seguintes itens: Escopo do Cliente (Requisitos); Principais Entregas
do Projeto; Limites do Projeto (Escopo não incluído); Critério de Aceite do Projeto;
Principais Estratégias para Condução do Projeto; Restrições e Premissas
(Hipóteses) (Carlos Magno S. Xavier, p.93 e 94).A declaração do Escopo deve ser assinada pelo gerente do projeto e pelas
principais partes interessadas (Stakeholders), considerados, dessa forma,
aqueles com envolvimento direto na alocação de recursos (patrocinador e
gerentes funcionais) e no recebimento das principais entregas (cliente)
(Carlos Magno S. Xavier, p.95).
22
2.2 MONITORAMENTO E CONTROLE DE ESCOPO
Segundo Ivo Michalick Vasconcelos et al, no livro Gestão de Projetos Brasil-
Conceitos e Técnica, IETEC (2012), com relação ao Monitoramento e controle do
escopo, um ponto importante é definir e utilizar um processo de acompanhamento
da geração do escopo, capturado na forma de suas entregas. Uma técnica
amplamente utilizada é a do acompanhamento do avanço físico (no sentido da
geração das entregas) do projeto ao longo do tempo.
O PMBOK, 4ª Edição (2009) define no item 3.6 - Grupo de Processos de
Monitoramento e Controle os seguintes processos, dos quais dois são diretamente
vinculados às garantias de escopo:
4.4 - Monitorar e controlar o trabalho do projeto4.5 - Realizar o controle integrado de mudanças5.5 - Verificar o escopo5.5 - Controlar o Escopo;
6.6 - Controlar o cronograma7.3 - Controlar os custos8.3 - Realizar o controle da qualidade10.5 - Reportar o desempenho11.6 - Monitorar e controlar os riscos12.3 - Administrar as aquisições
23
Monitorar e controlar o trabalho no projeto é o processo de
acompanhamento, avaliação e regulação do progresso para atender aos
objetivos de desempenho definidos no plano de gerenciamento do projeto.
O monitoramento inclui relatórios de status, medições do progresso e
previsões. Os relatórios de desempenho fornecem informações sobre o
desempenho do projeto com relação a escopo, cronograma, custo,
recursos, qualidade e risco, que podem ser usadas como entradas para
outros processos. (PMBOK, 4ª Edição, p. 61)
Verificar o escopo é o processo de formalização da aceitação das entregas
concluídas do projeto. Inclui a revisão das entregas com o cliente ou patrocinador
para assegurar que foram concluídas satisfatoriamente e obter deles a aceitação
formal das mesmas. A verificação do escopo difere do controle de qualidade, pois
está interessada principalmente na aceitação das entregas, enquanto que o segundo
se interessa com a precisão das mesmas e o alcance dos requisitos de qualidade
especificados para elas. O controle de qualidade é normalmente feito antes da
verificação do escopo, mas os dois processos podem ser executados paralelamente.
(PMBOK, 2009, p. 123).
5.4 Verificar o escopo: Verificar o escopo é o processo de formalização da aceitação das entregas terminadas do projeto. (PMBOK, 2009, p. 61)
5.5 Controlar o escopo: Controlar o escopo é o processo de monitoramento do andamento do escopo do projeto e do produto e gerenciamento das mudanças feitas na linha de base do escopo. (PMBOK, 2009, p. 62)
Controlar o escopo é o processo de monitoramento do andamento do escopo do
projeto e do produto e gerenciamento das mudanças feitas na linha de base do
escopo. O controle do escopo do projeto assegura que todas as mudanças
solicitadas e ações corretivas ou preventivas são processadas através do processo
Realizar o controle integrado de mudanças (PMBOK, 2009, p. 93 a 99).
O controle do escopo do projeto é usado também para gerenciar as mudanças reais quando essas ocorrerem e é integrado aos outros processos de controle. As mudanças não controladas são frequentemente chamadas de scope creep. A mudança é inevitável, exigindo, portanto, algum tipo de processo de controle de mudanças. (PMBOK, 2009, p. 125).
Enquanto o processo de “Controle de Qualidade” (um dos processos de
Gerenciamento da Qualidade do Projeto) está preocupado com a “exatidão do
resultado do trabalho", a “Verificação do Escopo” está querendo a “aceitação do
mesmo”. (XAVIER, 2005).
24
De acordo com o que se extrai do Guia PMBOK 4ª Edição (2009), para verificação
do escopo, como entrada, toma-se por referência o Plano de gerenciamento de
projeto, Documentação dos requisitos, Matriz de rastreabilidade dos requisitos e
Entregas validadas.
O Plano de gerenciamento do projeto integra e consolida todos os planos de
gerenciamento auxiliares e linhas de base dos processos de planejamento. O
referido plano pode ser conciso ou detalhado podendo ser constituído de um ou
mais planos auxiliares, planos esses detalhados conforme requerido no projeto. Uma
vez estabelecido o plano de gerenciamento do projeto, mudanças só poderão
acontecer, depois de agenciada a solicitação de mudança e a aprovação desta
através do processo Realizar o controle integrado de mudanças. (PMBOK, 2009)
A linha de base do escopo inclui a Declaração do escopo do projeto que inclui a
descrição do escopo do produto, as entregas do projeto e define o critério de
aceitação do usuário em relação ao produto, EAP: define cada entrega e a
decomposição das entregas em pacotes de trabalho e o Dicionário da EAP: que
possui uma descrição detalhada do trabalho e documentação técnica para cada
elemento da EAP. (PMBOK, 2009)
As linhas de base incluem, mas não está limitada a linha de base do cronograma,
linha de base do desempenho de custos e do escopo. O mesmo acontece com os
planos auxiliares que incluem, mas não estão limitados, ao Plano de Gerenciamento:
do escopo, dos requisitos, do cronograma, dos custos, da qualidade, de melhorias
no processo, de recursos humanos, das comunicações, dos riscos e aquisições.
(PMBOK, 2009)
A Documentação dos requisitos delineia como os requisitos individuais atendem às
necessidades do negócio para o projeto, podendo começar em alto nível e
progressivamente se tornar mais detalhados conforme mais detalhes são
conhecidos no desenvolvimento do projeto. Os requisitos devem ser mensuráveis e
passíveis de testes, investigáveis, completos, consistentes e aceitáveis para as
principais partes interessadas. A documentação de requisitos pode variar de uma
simples lista categorizada por partes interessadas e prioridades a formas mais
elaboradas contendo um resumo executivo, descrições detalhadas dentre outras.
(PMBOK, 2009)
25
A Matriz de rastreabilidade dos requisitos liga os requisitos às suas origens e os
rastreia durante todo o ciclo de vida do projeto. A utilização de uma matriz de
rastreabilidade ajuda a garantir que cada requisito adiciona valor de negócio através
da sua ligação aos objetivos de negócio e aos objetivos do projeto. Fornece um meio
de rastreamento do início ao fim do ciclo de vida do projeto, ajudando a garantir que
os requisitos aprovados na documentação sejam entregues no final do projeto.
Finalmente, fornece uma estrutura de gerenciamento das mudanças do escopo do
produto. (PMBOK, 2009)
A Matriz de rastreabilidade dos requisitos inclui, mas não está limitado ao
delineamento dos: Requisitos das necessidades do negócio, oportunidades, metas e
objetivos; objetivos do projeto; entregas do escopo/EAP do projeto; design do
produto; desenvolvimento do produto; teste de estratégia e de cenários e requisitos
de alto nível para requisitos mais detalhados. A Matriz de rastreabilidade deve
registrar os atributos associados a cada requisito, pois os mesmos auxiliam na
definição de informações chaves dos respectivos requisitos. (PMBOK, 2009)
Para a entrada Entregas validadas o Guia PMBOK – 4ª Edição (2009) informa que
as precisões das referidas entregas foram verificadas e validadas no processo 8.3
Realizar o controle da qualidade. (PMBOK, 2009)
Segundo Carlos Magno Xavier – Gerenciamento de Projetos (2005), a verificação do
escopo é realizada através de inspeções ou auditorias que verificam os resultados
do trabalho e vão assegurar que eles foram completados, realizados correta e
satisfatoriamente e estão conforme os requisitos definidos. Toda a documentação
dos deliverables, como planos, especificações, documentos técnicos e desenhos,
também deve estar completa, para que se possa então, obter a aceitação formal por
parte dos stakeholders.
Na verificação do escopo as saídas associadas são: Entregas aceitas, Solicitações
de mudança e Atualizações dos documentos do projeto. Segundo Carlos Magno
Xavier – Gerenciamento de Projetos (2005), o que se pretende é obter a aprovação
formal do escopo do projeto por parte de seus interessados. A formalidade da
aceitação tem dois objetivos principais: Cuidado na aceitação quando da validação
dos produtos e serviços que estão sendo entregues pelo projeto e Documentação
26
para deixar registrado quem aceitou o deliverable permitindo a continuidade do
projeto, principalmente a execução das atividades dependentes dessa aceitação.
Do Guia PMBOK – 4ª Edição (2009), quanto à verificação do escopo, se extrai:.1 Entregas aceitas
As entregas que estão de acordo com os critérios de aceitação são formalmente assinadas e aprovadas pelo cliente ou patrocinador. A documentação formal, recebida do cliente ou patrocinador confirmando a aceitação formal das entregas do projeto pelas partes interessadas é encaminhada ao processo Encerrar o projeto ou fase (4.6).
.2 Solicitações de mudança
As entregas finalizadas que não foram formalmente aceitas são documentadas, juntamente com as razões para a sua rejeição. Essas podem exigir uma solicitação de mudança visando o reparo de defeitos. As solicitações são processadas para revisão e distribuição no processo Realizar o controle integrado de mudanças (ver Seção 4.5).
.3 Atualizações dos documentos do projeto
Os documentos que podem ser atualizados como resultado do processo Verificar o escopo incluem quaisquer documentos que definam o produto ou relatem o progresso da conclusão do produto. (PMBOK, 2009, p. 125)
Para controlar o escopo, como entrada toma-se por referência o Plano de
Gerenciamento do projeto, Informações sobre o desempenho do trabalho,
Documentação dos requisitos, Matriz de rastreabilidade dos requisitos e Ativos de
processos organizacionais. (PMBOK, 2009)
O Plano de gerenciamento do projeto empregado para controlar o escopo é formado
pela: Linha de base do escopo que deve ser comparada aos resultados reais para
determinar se uma mudança, ação corretiva ou preventiva é necessária, Plano de gerenciamento do escopo.com a descrição como este será gerenciado e
controlado, Plano de gerenciamento das mudanças com a definição do processo
para gerenciar mudanças no projeto, Plano de gerenciamento da configuração com definição dos itens que requerem controle formal de mudança e o processo
para controlar as mudanças desses itens e do Plano de gerenciamento dos requisitos que descreve como as atividades de requisitos serão planejadas,
acompanhadas e relatadas e como as mudanças dos requisitos do produto, serviço
ou resultado serão iniciadas e como os impactos serão analisados e os níveis de
autorização necessários para aprovar tais mudanças. (PMBOK, 2009)
Para a entrada Informações sobre o desempenho do trabalho monitora-se o status
das entregas, informando se iniciadas, o progresso das mesmas e quais foram
concluídas. Para Documentação dos requisitos e Matriz de rastreabilidade dos
27
requisitos usa-se a mesma metodologia apresentada para Verificação de escopo.
(PMBOK, 2009)
Políticas, procedimentos e diretrizes existentes, formais ou informais, relacionadas
ao controle do escopo e Métodos de monitoramento e informação a serem utilizados
são Ativos de processos organizacionais que podem influenciar no controle do
escopo. (PMBOK, 2009)
Para controlar o escopo a ferramenta recomendada é Análise de variação onde se
avalia a magnitude da variação a partir da linha de base do escopo. Nessa avaliação
deve-se determinar da causa e grau de divergência relativa à linha de base do escopo e a
decisão se ações corretivas ou preventivas são necessárias. (PMBOK, 2009)
As saídas associadas para Controlar o escopo são: Medições de desempenho do
trabalho, Atualizações dos ativos de processos organizacionais, Solicitações de
mudança, Atualizações do plano de gerenciamento do projeto e Atualizações dos
documentos do projeto. (PMBOK, 2009)
As Medições do desempenho do trabalho podem incluir desempenho técnico planejado
versus real ou outras medições de desempenho do escopo, devendo ser documentada e
comunicada às partes interessadas.
As Atualizações de ativos de processos organizacionais podem ser atualizadas
considerando as causas das variações, a ação corretiva escolhida e suas razões e outros tipos
de lições aprendidas a partir do controle do escopo do projeto.
A análise do desempenho do escopo pode resultar numa Solicitação de mudança da linha de
base ou de outros componentes do plano de gerenciamento do projeto. Solicitações de
mudança podem incluir ações preventivas ou corretivas e reparos de defeitos.
Atualizações do plano de gerenciamento do projeto resultam na atualização da linha de
base do escopo. Se as solicitações de mudança aprovadas afetam o escopo do projeto, então a
declaração deste, a EAP e o dicionário da EAP são revisados e publicados novamente para
refletir as alterações aprovadas.
Outras atualizações da linha de base. Se as solicitações de mudança aprovadas afetam o
escopo do projeto, então as linhas de base dos custos e do cronograma correspondentes são
revisadas e publicadas novamente para refletir as alterações aprovadas.
28
Documentação dos requisitos e Matriz de rastreabilidade de requisitos são Documentos que
devem ser atualizados. (PMBOK, 2009, p. 128)
No artigo técnico “A importância da gestão de escopo em projetos” Ilmário Rocha
Brito (2008) afirma que durante a execução de um projeto, é inevitável a ocorrência
da solicitação de mudança de escopo do projeto. Um fator crítico de sucesso do
projeto é a condução do processo de mudança de escopo do projeto. O processo de
controle de mudanças no escopo é o processo responsável por, de forma
organizada e controlada, receber a solicitação de mudança, avaliar seus impactos
no projeto, obter sua aprovação a quem de direito e refletir as mudanças solicitadas
e aprovadas na linha de base do projeto.
De acordo com KERZNER & SALADIS no livro Gerenciamento de Projetos
Orientado por Valor (2009) é reconhecida a necessidade de mudança em face de
situações de percurso que assim o exigem:Seguir um plano de projeto até a conclusão nem sempre será garantia de sucesso, se no decorrer do processo mudanças relacionadas ao negócio forem necessárias, mas nunca implementadas. (KERZNER e SALADIS, 2009, p. 60)
29
2.3 GESTÃO DE MUDANÇAS DE PROJETOS
Pela evolução das incertezas em um projeto, conforme já mostrado na Figura 2-2
retirada da 4ª Edição do PMBOK (2009), pode ser afirmado que é natural a
ocorrência de algumas solicitações de mudanças ao longo do projeto. Tal afirmativa
também pode ser embasada no rito processual normal de um projeto, pois à medida
que se dá o avanço em um determinado projeto, algumas premissas adotadas
podem se mostrar incorretas, ou incompletas para se atingir o fim ao qual o projeto
se propõe. Da mesma forma, algumas oportunidades e riscos se apresentam ao
longo do período do projeto, tais como: como novas tecnologias, decisões
governamentais ou mudanças no cenário econômico, todas podem forçar o projeto a
uma mudança de rumo para que o mesmo se mantenha viável economicamente.
Naturalmente, mudanças em projetos causam impactos (DUARTE et al, 2009 e
VALERIANO, 2002) e estes precisam ser quantificados e estudados de uma forma
global, envolvendo todas as áreas de conhecimento da gestão de projetos para que
estes impactos sejam mensurados e todos os envolvidos tenham a mais rigorosa
condição de avalia-los. É de suma importância que a mensuração dos impactos seja
correta, pois, uma vez decidida a adoção das mudanças e a continuidade do projeto,
tais impactos não venham demonstrar resultados nebulosos e nefastos que levem o
projeto ao fracasso ou que faça com que os desvios de prazo e custo o torne
desinteressante para o stakeholder principal (patrocinador) e/ou para os demais
stakeholders interessados no sucesso do projeto e que tenham poder alto poder de
interferência. Conforme defendido por Barcaui (2012), mudanças somente devem
ser empregadas, seja em projetos ou até mesmo na operação de empreendimentos,
se as mesmas forem positivas, isto é, se contribuírem ao resultado final esperado do
objeto que sofrerá tais modificações.
Coutinho & Garcia (2012) ponderaram que projetos são feitos por pessoas. Isso nos
leva a incluir mais uma análise em situações de grandes mudanças em projetos.
Kerzner (2003) apresenta uma sequência de comportamentos que as pessoas
demonstram frente a situações de mudança. Apesar de seu intuito principal ser
mudanças em ambientes corporativos, mudanças de processos e a mudanças de
estruturas organizacionais, o estudo também pode ser aplicado à realidade de
30
projetos. A Figura 2-3 extraída do trabalho KERZNER (2003) apresenta uma
adaptação do comportamento usual conforme apontado no trabalho.
Figura 2-3: Resposta humana a situações de mudança
Vários são os motivos apontados para tal comportamento, variando desde
acomodação, passando por medo do novo, medo de não ser capaz de realizar o
trabalho alterado, até o efeito psicológico de se ter todo um esforço abandonado
para realinhar a direção do projeto ou da organização. Em uma corporação,
normalmente há tempo suficiente para que o processo de mudança seja
implementado de forma paulatina a fim de se ter a interação integral à nova
realidade. Porém, devido à natureza temporária de um projeto essa resistência
natural à mudança pode fazer com que o projeto não atinja suas principais metas e,
assim, perca sua razão de ser. Portanto, é imprescindível que toda mudança seja
medida, acompanhada e controlada de forma adequada para que o projeto proceda
às entregas definidas e obtenha o sucesso almejado.
Analisando-se as diferenças entre uma mudança gerenciada e uma mudança não
gerenciada, é evidente que a primeira opção é a mais indicada para se ter um
projeto controlado e para se manter um nível baixo de riscos no mesmo. Com o
gerenciamento, as pessoas já possuem ciência das possibilidades de mudança
antes mesmo da necessidade das mesmas. Isso ajuda a se manter um clima de
trabalho no projeto que facilite a condução de mudanças, sem que a equipe técnica
do projeto ofereça grandes resistências às mudanças.
31
KERZNER, 2003, apresenta um quadro no qual contrabalanceia uma mudança
gerenciada e uma mudança não gerenciada. A Tabela 2-1 apresenta uma adaptação
de tal quadro para facilitar o entendimento da discussão do tema.
Quando o tempo é investido?
Como o esforço é investido?
Quais são os recursos humanos
necessários?
Mudança Gerenciada
Antes da mudança ocorrer
Educação;Comunicação;
Orientação;Planejamento;
Melhorias;Valor Agregado;
Stakeholders internos;Fornecedores;
Clientes;
Mudança não Gerenciada
Após a ocorrência da mudança
Retrabalho;Supervisão;Cobrança;
Trabalho extra;Força-tarefa;
Gerente Sênior;Funcionários-chave;
Tabela 2-1: Diferença de esforço e recursos necessários entre mudanças gerenciadas e mudanças não gerenciadas
No gerenciamento de mudanças, é primordial que toda decisão tomada seja
registrada, acordada entre as partes interessadas e comunicada aos envolvidos para
que sejam aderidas ao projeto. É fortemente recomendado que toda mudança
significativa leve à geração de um aditivo contratual, ou algum outro documento com
força legal, para justificar a reflexão das novas situações às linhas de base de
escopo, custo e prazo do projeto. Conforme defendido pelas boas práticas traçadas
no PMBOK (2009), as mudanças devem ser incorporadas ao planejamento do
projeto e controladas quanto a todas as áreas de conhecimento. É definido que fica
a cargo do responsável pelo projeto (GP) definir como o controle se dará, podendo
optar por realiza-la através da análise única de projeto + alteração ou através da
análise das duas entidades separadas, mas com gestão integrada. Em um
determinado projeto, podem ser traçadas duas funções sempre presentes:
contratado e contratante, independentemente se há mais de uma instituição
envolvida ou se as relações se dão internamente a uma instituição. A relação entre
essas duas entidades deve ser sempre construída de forma a facilitar o sucesso do
projeto que é conduzido, o que não tira o mérito de discussões a cargo de
responsabilidades em mudanças ou decisões errôneas em projetos. Dessa forma,
podem ser afirmadas que mudanças de projeto causadas por erros da contratada
devem ter o ônus assumido pela mesma, mas que esta tem o direito de questionar e
exigir compensação caso as mudanças sejam oriundas de erros ou decisões da
32
contratante. Para que se tenha uma relação saudável entre contratante e contratada,
é fundamental que alguns cuidados sejam tomados. Uma matriz de
responsabilidades designando os envolvidos autorizados a aprovar as mudanças em
ambas às partes, bem como o nível em que poderão atuar, é fundamental para que
se tenha um controle adequado e mais seguro de todas as alterações no projeto. Da
mesma forma, é vital que toda evidência que seja gerada, seja registrada e
armazenada ao longo do projeto, a fim de garantir provas documentais e
disponibilizar argumentos fundamentados para a defesa das partes em discussões
sobre as responsabilidades que deverão assumir. Porém, vale ressaltar que todo
este cuidado deve ser conduzido de forma honesta e transparente. Tendo em vista a
relação contratante-contratada, pode ser afirmado que toda mudança em projetos
não causada por erros da contratada deve ser iniciada através de uma solicitação de
mudança (change order), contra a qual será apresentada uma reivindicação ou pleito
(claim). WIDEMAN,1990, define uma reivindicação e/ou pleito como uma
oportunidade de se recuperar os custos de um trabalho dado como perdido ou ainda
como uma oportunidade de ressarcimento frente a uma situação onde o pacto
contratual assumido ao início do projeto não expressa o ocorrido. Coutinho & Garcia
(2012) abordam de forma complementar que uma reivindicação e/ou pleito é um
pedido legítimo de compensação adicional de custo e/ou prazo da contratada frente
à contratante. WIDEMAN,1990, expressou que uma reivindicação e/ou pleito é
válida quando se vê frente a uma ou mais de quatro situações primordiais a seguir:
Quando situações previamente acordadas são alteradas, tais como requisitos do
projeto, requisitos do produto-fim, escala do projeto, etc.;
Quando ocorrem trabalhos extras, seja por serviços acima do preço e prazo
combinados ou pela execução de serviços necessários que não eram
abrangidos pelo escopo inicial;
Quando se tem atrasos causados pela contratante;
Quando se tem divergências entre a requisição de tempo extra para o contrato,
em função de mudanças nas condições iniciais ou pelos atrasos causados pela
contratante.
Frente a tais colocações, os envolvidos na gestão de um projeto se veem
necessitados de ferramentas e processos para controle de tais situações. Para tal
controle, COUTINHO & GARCIA, 2012, propuseram algumas regras a fim de nortear
a atuação de um gestor de projetos no que tange à gestão das evidências geradas
33
ao longo da execução de um projeto. As regras propostas estão descritas abaixo, de
forma fiel à encontrada no artigo:
1. Determinar quais registros devem ser mantidos, e como;
2. Estabelecer log dos registros, para que eles possam ser encontrados, referidos
e/ou acompanhados, sempre que necessário;
3. Estabelecer padrão de referência, listas e codificação de todos os seus
contratos. Isso facilita enormemente a gestão, analisando e comparando
contratos;
4. Uma vez que os registros tenham sido identificados, garanta que eles são, de
fato, criados, mantidos e utilizados para gerir o trabalho;
5. Rever o sistema de registro de tempos em tempos, porque registros têm o
“hábito” de crescimento em formas inesperadas, “aparecendo” em partes em
locais inconvenientes;
6. Além disso, alguns registros podem se tornar obsoletos ou redundantes, e
devem ser analisados, consolidados e descartados;
7. Observar que registros também ocupam espaço e equipamentos. Determinar a
vida útil dos diversos componentes, e ter uma abordagem sistemática para a
eliminação do registro;
8. Tomar medidas para assegurar a precisão, confiabilidade e, por conseguinte
credibilidade dos registros, os quais sem a devida credibilidade podem ser
bastante inúteis. Enfim, importante salientar que os registros são em última
análise a garantia de recomposição e comprovação dos direitos contratuais
surgidos em função de imprevisibilidades ou das inadimplências contratuais e
têm um papel de extrema importância, uma vez que as pessoas envolvidas nas
relações contratuais podem ser substituídas ao longo do tempo, restando assim
os dados coletados durante a execução do contrato.
As reivindicações devem ser realizadas sempre que houver mérito por parte da
contratada, valendo-se da negociação franca e transparente dos pontos levantados.
Dessa forma, é importante levantar que as mesmas devem ser apresentadas de
forma anterior à execução das alterações sempre que possível for, a fim de impedir
que a contratante seja lesada por custos previamente desconhecidos e por decisões
que não levaram em conta os impactos inerentes a uma mudança. Tal raciocínio
parte do gráfico apresentado na Figura 2-2. Neste gráfico é possível notar que o
34
custo de mudanças aumenta de forma considerável ao longo do projeto à medida
que as incertezas decaem. Isso significa que uma mudança precipitada pode causar
um prejuízo significativo caso a alteração não se mostre eficiente, o que pode levar o
projeto à inviabilidade financeira e, consequentemente, ao insucesso. Caso o projeto
possua um prazo final que não permita o estudo dos impactos de forma anterior à
formalização e implantação das mudanças propostas, é indicado que tal estudo seja
realizado de forma paralela para que se tenha informações acerca da situação o
mais cedo possível, além de ser vital o envolvimento do patrocinador do projeto para
que este esteja ciente do risco existente de se realizar uma alteração antes de se
conhecer os impactos plausíveis.
Vale ressaltar a importância de se ter um processo bem definido para a gestão de
mudanças e para a gestão de evidências dentro do projeto, para que todos os
stakeholders atinjam seus interesses principais com o sucesso do projeto e que
nenhum dos mesmos se sinta prejudicado ou lesado durante a condução do projeto.
35
2.4 GERENCIAMENTO DE ESCOPO – VARIANTES EM FUNÇÃO DO TIPO DE CONTRATO
Fatores como as modalidades de contrato podem influenciar na gestão do escopo e
afetar a relação entre as partes no que tange as mudanças e pleitos futuros.
Modalidade de contratos:
Segundo Relatório Técnico nº 99 642-205 - 35 publicado no site
www.revistatechne.com.br_Engenharia-civil, podemos identificar atualmente
algumas modalidade de contratos praticadas no mercado e suas variantes, a saber:
Contrato do tipo Preço Unitário (PU), em que o detalhamento do projeto básico, ou seja, o projeto executivo é elaborado por uma projetista contratada diretamente pelo proprietário do empreendimento e a partir desse segue-se a construção, totalmente guiada pelo projeto. A construtora vencedora da licitação é remunerada pelos serviços executados, de acordo com os preços unitários estabelecidos em sua proposta apresentada na licitação. Internacionalmente é conhecido como Design-Bid-Build (DBB) também conhecida como Engineering - Procurement - Construcion (EPC) (GOMES, 2006).
No contrato do tipo Preço Global (PG), o projeto executivo constitui-se em encargo da entidade executora e é elaborado por uma projetista, que é parte dessa entidade ou subcontratada por ela. A execução da obra é realizada por um preço global fixo, estabelecido na proposta da entidade executora apresentada na licitação, e a remuneração é efetuada de acordo com os termos estipulados no contrato. Internacionalmente é conhecido como Design-Build (DB), ou simplesmente contrato turnkey.
Há variantes dessas duas modalidades de contratação. Um terceiro tipo, por exemplo, conhecido como Design-Build-Operate (DBO), é também ocasionalmente utilizado, principalmente em projetos que envolvem concessão de operação, mas nesse tipo de contrato, a parte referente à construção não difere dos contratos por preço global (PG ou DB).
A modalidade de contratação DBO assemelha-se a modalidade os contratos tipo
Parceria Público Privado - PPP, do setor público com o setor privado.
Na modalidade de contratação do tipo preço unitário o proprietário do
empreendimento (ou cliente), a empresa de projetista e o construtor estabelecem
uma relação de três partes independentes, onde cada parte deve se relacionar com
as outras duas conforme figura abaixo:
36
Na forma de contratação do tipo Preço Global (PG ou DB) o proprietário se
relaciona apenas com uma parte, que é a entidade executora, formada pela
construtora e suas subcontratadas, e pela projetista conforme figura abaixo:
Nessa modalidade, o projeto básico elaborado para a licitação e a contratação é
mais simplificado, sendo fornecidas apenas as diretrizes principais do
empreendimento e as especificações técnicas e de desempenho relevantes,
deixando para a entidade executora a escolha de métodos, serviços e
materiais, desde que o produto final atenda às especificações técnicas e de
desempenho contratadas.
A principal vantagem dos contratos do tipo Preço Global (PG ou DB) é que o
proprietário tem que se relacionar apenas com a entidade executora, o que
simplifica o processo de comunicação entre as partes e a administração dos
contratos gerenciados pelo proprietário. Adicionalmente, o processo de licitação
37
pode ocorrer mais cedo na escala do tempo de desenvolvimento do
empreendimento, pois uma parte substancial da complementação e detalhamento
do projeto será executada pela entidade executora, após a adjudicação do
contrato. Esses fatores normalmente reduzem prazos e custos, na fase de pré-
licitação do empreendimento. Ademais, nessa modalidade é minimizada a
ocorrência de longos e custosos litígios e evitam-se negociações sobre mudanças
nas condições. Outras vantagens decorrem da interação mais cedo da
construtora com a empresa projetista, tais como: apresentação de contribuições
ao projeto, identificação e discussão de aspectos de construção etc.
A figura a seguir mostra a relação entre os tipos de contrato, os graus de risco
correspondentes ao proprietário e à construtora e os custos finais relativos do
empreendimento (CIRIA, 1978).
Portanto, pela cima exposto, verifica-se que a modalidade de contratação influencia
no processo de comunicação, qualidade das informações disponíveis para
relacionamento em os principais stakeholders e riscos de custos do projeto.
38
2.5 REEQUILÍBRIO ECONÔMICO-FINANCEIRO
FERREIRA & GUÉRIOS, 2011, através do artigo "Função social" e equilíbrio
econômico-financeiro dos contratos, privados e administrativos, expressam a
situação realista que se convive no meio do direito em face das necessidades de
repactuação dos contratos decorrentes de interferências prioritariamente externas
que desequilibram a equação financeira primeira que forjou as condições comerciais
iniciais. Tais ocorrências vêm a baila e necessitam serem instruídas de modo
completo e consistente, demonstrando o desequilíbrio incorrido, as causas e as
consequências que, via de regra, se não repactuadas, inviabilizam a continuidade do
objeto contratado.Muito já se investigou, no Brasil, acerca do equilíbrio econômico-financeiro
dos contratos de “direito privado” e de “direito público”. Contudo, são
praticamente inexistentes as reflexões acerca da “justiça contratual” como
conditio sine qua non de validade comum, trazendo a lume – e em cotejo –
os contratos privados e os ditos administrativos. Melhor dizendo, ou bem se
estuda o Código Civil (Lei nº 10.520/2002) ou a Lei Geral de Licitações (Lei
nº 8.666/93), tão-só. (FERREIRA & GUÉRIOS, 2011)
39
3 SOLUÇÕES PROPOSTAS
(Conforme experiência dos componentes do grupo e conhecimento de soluções implantadas em
outras empresas, da pesquisa bibliográfica ou observações das operações atuais, ou identificação
das fontes de desperdício, deve-se efetuar proposição de novo modelo. Cada membro do grupo deve
contribuir dentro da linha do subtema que lhe compete, lembrando-se do foco geral do TCC e sempre
se reportando a este para fiz de amarração e interação.).
TEMA ALUNO
DECLARAÇÃO DE ESCOPO
MONITORAMENTO E CONTROLE DE
ESCOPO
GESTÃO DE MUDANÇAS DE PROJETOS
GERENCIAMENTO DE ESCOPO –
VARIANTES EM FUNÇÃO DO TIPO DE
CONTRATO
REEQUILÍBRIO ECONÔMICO-
FINANCEIRO
40
3.1 DECLARAÇÃO DE ESCOPO
A Declaração do Escopo do Projeto detém grande importância no desenvolvimento e
controle do projeto, pois se na elaboração da mesma não forem bem avaliadas e
consideradas as premissas, restrições, exclusões, dentre outras, poderão ser
criadas situações de riscos podendo culminar em prejuízos financeiros e até mesmo
na inviabilidade do projeto.
Partindo da premissa que a Declaração do Escopo do projeto descreve, em
detalhes, as entregas do projeto e todo desdobramento necessário para criar essas
entregas, bem como fornece um entendimento comum do escopo do projeto a todos
os stakeholders apresentando detalhamento dos principais objetivos do projeto.
Considerando que o desenvolvimento de uma declaração do escopo detalhada do
projeto, como sendo a base para futuras decisões do projeto, o presente trabalho
focará nos pontos fundamentais que influenciam na Declaração de Escopo. Analisar
e entender o escopo inclui os requisitos do projeto e produto, critérios, premissas,
restrições, exclusões e outras influências relacionadas ao projeto e como cada um
será gerenciado ou discutido dentro do projeto.
O escopo de um projeto especifica seu produto principal e as entregas (deliveries)
ao longo do projeto. O escopo do projeto é descrito como “A soma dos produtos
(receptivos = deliverables) e serviços a serem fornecidos como um projeto” (PMI).
Isso implica uma decisão clara sobre resultados essenciais, ou seja, a medida na
qual o projeto atenderá “necessidades e desejos” e que receptíveis ou produtos
desejáveis, mas não essenciais, poderão ser incluídos ou omitidos, resultando em
objetivos principais claros, critérios de sucesso, custos da qualidade e duração.
(KEELLING, 2005, p. 190).
41
3.2[3.1] MONITORAMENTO E CONTROLE DE ESCOPO
Saber conduzir as atividades no plano do projeto e montar um sistema de controle
que seja compatível com a dimensão e as urgências do projeto é fundamental.
Apoiado nesta afirmativa o presente trabalho objetiva nortear profissionais de projeto
sobre a importância de definir papéis e responsabilidades distintas no ambiente de
projeto, devendo ser assumidos para que ambas as funções – execução e controle
possam ser concluídos satisfatoriamente. Também sugerir templates para efetivar o
monitoramento e controle do escopo com ênfase em gestão de mudanças, quando
ocorrer.
É importante afirmar que o gerenciamento do escopo é a base para a construção
dos demais processos de gerenciamento de projeto, e que deverá ficar latente para
todos os players o limite do projeto, as premissas do projeto, quais os pacotes de
trabalhos, quais são as entregas, dentre outras informações.
Se não tivermos realizado um bom trabalho para definir o escopo, o seu
gerenciamento, traduzido pelo monitoramento e controle será quase impossível o
que contribuirá para o insucesso do projeto.
42
3.3[3.2] GESTÃO DE MUDANÇAS DE PROJETOS
Tendo em vista as dificuldades observadas no mercado brasileiro frente ao
gerenciamento de mudanças em projetos e, consequentemente, às reivindicações
pertinentes, o presente trabalho se propõe à formatação de um processo base para
condução do gerenciamento de pleitos e das mudanças passíveis de ocorrência em
projetos. Tal modelo vem oferecer a gestores de projeto mais uma opção para um
maior controle e um melhor acompanhamento da evolução de seus projetos frente
aos interesses dos stakeholders, à realidade que orbita os projetos e às linhas de
base de escopo, de prazo e de custo, todas utilizadas como referência na condução
dos mesmos. Tal processo base englobará o gerenciamento de mudanças desde as
fases de início de um projeto até seu encerramento, tendo em vista os cuidados
necessários e os fluxos pertinentes à aprovação, ao planejamento e à consolidação
e adição das mudanças às linhas de base do projeto alterado.
43
3.4[3.3] GERENCIAMENTO DE ESCOPO – VARIANTES EM FUNÇÃO DO TIPO DE CONTRATO
Fatores relativos a modalidade de contrato podem influenciar na gestão do escopo,
a relação entre as partes, as adequações e mudanças e consequentemente os
pleitos futuros.
Com a diversificação das modalidades de contratação atualmente no mercado; na
busca de redução de prazos e custos dos projetos; que alteram as condições de
responsabilidades das partes e o fluxo de informações necessárias para o
identificação e desenvolvimento do escopo, premissas, exclusões e restrições dos
projetos, este trabalho propõe o entendimento dos impactos destas diferentes
modalidades de contratação em relação aos pleitos durante o ciclo de vida do
projeto.
44
3.5[3.4] REEQUILÍBRIO ECONÔMICO-FINANCEIRO
45
4 PLANO DE PROJETO DE IMPLANTAÇÃO
(Cada aluno deve escolher uma das soluções e propor um plano de implantação
conforme plano de projeto aprendido no módulo de aperfeiçoamento, contendo:
escopo, prazo, custo, qualidade, recursos humanos, comunicação, riscos e
aquisições).
46
5 CONCLUSÕES E RECOMENDAÇÕES
(Síntese dos objetivos do trabalho e de como foi feito. Conclusões na forma da
resposta (s) a questão chave formulada. Recomendações para a prática e/ou teoria.
Desenvolvimento individual).
47
6 REFERÊNCIAS BIBLIOGRÁFICAS
Project Management Institute. Um guia do Conjunto de Conhecimentos em Gerenciamento de Projetos (Guia PMBOK) - 4ª Edição. Pennsylvania: PMI, 2009.
SANTOS, Diogo Nei – 10 Dicas para Definir o Escopo do Projeto. papogp.com/2009/05/26/10-dicas-para-definir-o-escopo-do-projeto/, 2009.
KERZNER, H. - Gerenciamento de Projetos - Uma Abordagem Sistêmica para Planejamento, Programação e Controle - 10ª Edição. São Paulo: Blucher, 2011
MERIGUETTI, Cézar e DINSMORE, P - Mitigando Fracassos em Projetos através da Comunicação (abordagem PMI). www.slideshare.net/DAssociates/mitigando-fracassos-em-projetos-atravs-da-comunicao-abordagem-pmi-12974264, 2012.
VASCONCELOS, Ivo M. M., BOYADJIAN, João C. e outros - Gestão de Projetos Brasil - Conceitos e Técnicas. Belo Horizonte: IETEC, 2012.
XAVIER, Carlos Magno - Gerenciamento de Projetos - Como definir e controlar o escopo do projeto. São Paulo: Editora Saraiva, 2005.
BRITO, Ilmário Rocha - A importância da gestão de escopo em projetos. www.techoje.com.br/site/techoje/categoria/detalhe_artigo/406 , IETEC, 2008.
KERZNER, Harold e SALADIS, Frank P. - Gerenciamento de Projetos Orientado por Valor. Porto Alegre: Artmed Editora, 2009.
DUARTE, Aline et al. Implantação do Gerenciamento de Mudanças de Escopo. Belo Horizonte: IETEC, 2009.
VALERIANO, D. L., Gerência de Projetos: Pesquisa, Desenvolvimento e Engenharia. São Paulo: Makron Books, 2002.
BARCAUI, André. PMO – Escritório de Projetos, Programas e Portfólio na prática. Rio de Janeiro: Ed. Brasport, 2012.
COUTINHO, Ítalo; GARCIA, Edson. Pleitos em Projetos Industriais: gestão de registros. Artigo Técnico no Portal Techoje, IETEC, 2012. http://www.techoje.com.br/site/techoje/categoria/detalhe_artigo/1218, acesso em 27/02/2013.
KERZNER, Harold. Project Management – A System Approach to Planning, Scheduling and Controlling – Eighth Edition. New Jersey: Hoboken, 2003.
WIDEMAN, R. M. Construction Claims: Identification, Communication & Record Keping. TUNS/Revay seminar, 1990.
VARGAS, Ricardo Viana. Gerenciamento de Projetos – Estabelecendo Diferenciais Competitivos. 3ª Ed. Ver. Rio de Janeiro, Ed. Brasport, 2007.
48
MULCAHY, Rita; DIETHELM, Laurie. Preparatório para o exame de PMP. 7ª Ed. EUA, Ed. RMC Publications, 2011.
POSSI, Marcus e outros. Gerenciamento de Projetos - Guia do Profissional Vol. 3: Fundamentos Técnicos. Ecthos/Brasport, 2006.
5 TENDÊNCIAS ATUAIS DE CONTRATAÇÃO E GERENCIMENTO.www.revistatechne.com.br/engenharia-civil/136/imagens/Relatorio_5.1.pdf
BEZERRA, João Arthur de Freitas- O Contrato EPC para Construção de Grandes Obras de Engenharia. Trabalho de monografia Universidade Católica de Salvador.http://info.ucsal.br/banmon/Arquivos/Mono3_0131.pdf
FERREIRA, Daniel; GUÉRIOS, Patricia Borges. "Função social" e equilíbrio econômico-financeiro dos contratos, privados e administrativos. In: Âmbito Jurídico, Rio Grande, XIV, n. 89, jun 2011. www.ambito-juridico.com.br/site/index.php?n_link=revista_artigos_leitura&artigo_id=9548, 2011.