1364175776 1363710199 tcc - gerenciamento de escopo com enfase em pleitos entrega ii...
DESCRIPTION
TCC - Gerenciamento de ProjetosTRANSCRIPT
Instituto de Educação Tecnológica
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
2
Belo Horizonte, MGMarçoio/2013
3
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 Instituto de Educação Tecnológica como requisito parcial à obtenção do título de especialista em Gestão de Projetos.
Orientador: João Carlos Araújo da Silva Neto
4
Belo Horizonte, MGMarçoio/2013
5
ONDE ESTÃO A LISTA DE FIGURAS, A LISTA DE ABREVIATURAS?????
6
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.
7
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, Sscope Declaration, Scope monitoring and control
and Pleasmonitoring and applications.
8
LISTA DE FIGURAS
Figura 1 - Grupos de Processos (PMI) ......................................................................11
Figura 2 - Causas de Fracassos ................................................................................13
Figura 3 - Nível de custos e pessoal ao longo do ciclo de vida .................................14
Figura 4 - Impacto da variável com base no tempo decorrido de projeto ..................14
Figura 5 - Fluxo de Atividades (relacionamentos) - PMI ............................................15
Figura 6 - ...................................................................................................................17
Diagrama de fluxo de dados do processo - desenvolver TAP ...................................18
Figura 8 ......................................................................................................................24
Figura 9 - Custo da mudança de escopo ...................................................................24
Resposta humana a situações de mudança ..............................................................29
Figura 11 - Relações entre as partes em contratos por preço unitário ( PU ou DBB)
...................................................................................................................................36
Figura 12 - Relações entre partes em contratos por preço global (PG ou DB) .........36
Figura 13 - Relação entre os tipos de contratos e os graus de riscos de custo ( Círia
1978) ..........................................................................................................................37
Figura 1 - Grupos de Processos (PMI) ......................................................................21
Figura 2 - Causas de Fracassos ................................................................................25
Figura 3 - Nível de custos e pessoal ao longo do ciclo de vida .................................13
Figura 4 - Impacto da variável com base no tempo decorrido de projeto ..................14
Figura 5 – Diagrama de fluxo de dados do processo - Definir o escopo ...................16
Figura 6 - Diagrama de fluxo de dados do processo - desenvolver TAP ...................17
Figura 7 - Grupo de processos de monitoramento e controle ....................................23
Figura 8 - Custo da mudança de escopo ...................................................................24
Figura 9 - Resposta humana a situações de mudança ..............................................31
9
Figura 10 - .................................................................................................................37
Figura 11 ....................................................................................................................37
Figura 12 ....................................................................................................................38
Figura 1 – Grupos de Processos (PMI) 10
Figura 2 – Causas de Fracassos 13
Figura 3 - Nível de custos e pessoal ao longo do ciclo de vida 13
Figura 4 - Impacto da variável com base no tempo decorrido de projeto 13
Figura 5 – Diagrama de fluxo de dados do processo - Definir o escopo 16
Figura 6 - Diagrama de fluxo de dados do processo - desenvolver TAP 17
Figura 7 - Resposta humana a situações de mudança 30
Figura 8 - 36
Figura 9 36
Figura 1 – Grupos de Processos (PMI) 9
Figura 2 – Causas de Fracassos 12
Figura 3 – Diagrama de fluxo de dados do processo - Definir o escopo (PMBOK -
2009) 15
10
LISTA DE QUADROS
Nenhuma entrada de índice de ilustrações foi encontrada.Nenhuma entrada de
índice de ilustrações foi encontrada.
11
LISTA DE TABELAS
Tabela 1 - Diferença de esforço e recursos necessários entre mudanças
gerenciadas e mudanças não gerenciadas ...........................................................3032
Nenhuma entrada de índice de tabelasilustrações foi encontrada.
E a tabela com os subtemas e autores responsáveis ????
12
LISTA DE SIGLAS E UNIDADES
GMP – Gerente de Múltiplos Projetos.
TAP – Termo de Abertura do Projeto.
DBB – Design-Bid-Build.
EPC – Engineering - Procurement – Construcion.
DBO – Design-Build-Operate.
PG – Preço Global.
DB – Design-Build.
DB Design-Build
DBB Design-Bid-Build
DBO Design-Build-Operate
DT Declaração de Trabalho
EAP Estrutura Analítica de Projetos
EPC Engineering - Procurement - Construction
GMP Gerente de Múltiplos Projetos
PG
PPP
Preço Global
Parceria Público Privada
TAP Termo de Abertura do Projeto
13
SUMÁRIO
1 INTRODUÇÃO ..................................................................................................912
2 REFERENCIAL TEÓRICO .............................................................................1114
2.1 Declaração do Escopo ...........................................................................1615
2.2 Monitoramento e Controle do Escopo ..................................................2423
2.3 Gestão de Mudanças de Projetos .........................................................2828
2.4 Gerenciamento de Escopo Variantes em Função do Tipo de Contrato
3434
2.5 Reequilíbrio Econômico-Financeiro .....................................................3837
3 SOLUÇÕES PROPOSTAS .............................................................................4240
3.1 Declaração do Escopo ...........................................................................4442
3.2 Monitoramento e Controle do Escopo ..................................................4543
3.3 Gestão de Mudanças de Projetos .........................................................4644
3.4 Gerenciamento de Escopo Variantes em Função do Tipo de Contrato
4745
3.5 Reequilíbrio Econômico-Financeiro .....................................................4846
4 PLANO DE PROJETO DE IMPLANTAÇÃO ..................................................5048
5 CONCLUSÕES E RECOMENDAÇÕES .........................................................5149
6 REFERÊNCIAS BIBLIOGRÁFICAS ...............................................................5250
121715232935383941424344454647489
12D15M23G29G35R38
39D40M41G42G43R44
45
46
471 INTRODUÇÃO 6
2 REFERENCIAL TEÓRICO 9
3 SOLUÇÕES PROPOSTAS 10
4 PLANO DE PROJETO DE IMPLANTAÇÃO 11
14
5 CONCLUSÕES E RECOMENDAÇÕES12
6 REFERÊNCIAS BIBLIOGRÁFICAS 13
15
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, promovampromovam 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, inicialmente 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 e que deve
ser grafada no Termo de Abertura do Projeto – TAP (Project Charter) de maneira
clara, sucinta e que represente o melhor possível o alicerce do objeto do projeto,
além de definir o Gerente do Projeto.
Conforme definido na NBR: ISO 10.006 (2003, p. 2), “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 TAPC (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), tudo de modo a se obter a
melhor definição do objeto do projeto, características, limites e . (PMBOK,
2009)condições de aceitação.
Da literatura especializada fica tácita a necessidade do emprego do maior esforço
16
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.
17
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 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, p).
Figura 1 – - Grupos de Processos (PMI)
Fonte: Araújo (2012)
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)
18
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á
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
19
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, partindo-se do aprimoramento da Definição de Escopo, focando a
com minimização da quantidade e abrangência de pleitos derivados da imprecisão
dos documentos de caracterização do objeto.
20
2 REFERENCIAL TEÓRICO
Figura 2 - Grupos de Processos (PMI)Figura 3 - Grupos de Processos (PMI)Fonte: Araújo (2012)1
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
1 Wladmir Araújo - Apresentação Gerenciamento De Projetos com PMBOK e FEL, disponível em: www.slideshare.net/wladmir_araujo/gerenciamento-de-projetos-com-pmbok-e-fel
21
é 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á
derivar para o caos, não atingindo as metas/parâmetros e, até, podendo chegar a
sucumbência, gerando pesados ônus para os patrocinadores.
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.
Do Kerzner (2011, p. 5833).), se extrai um panorama bem atual do modus operandi
atual no ambiente de projetos:
Pouquí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), (KERZNER, 2011, p. 583).
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ÇÃO
Pouquí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
22
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 Kerzner (2011) ainda menciona que 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 Meriguetti2 com a participação de Paul Campbell Dinsmore, (Maio/2012), é
possível coletar dados contidosapresentou dados muito significativos na Figura 4 -
Causas de Fracassos onde, apesar de estar 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,
registrando que o universo pesquisado foi de 300 empresas de grande porte.
2 Cézar Meriguetti com a participação de Paul Campbell Dinsmore - Palestra Mitigando Fracassos em Projetos, Maio/2012, disponível em www.slideshare.net/DAssociates/mitigando-fracassos-em-projetos-atravs-da-comunicao-abordagem-pmi-12974264.
23
Figura 4 -–- Causas de FracassosFonte: http://www.slideshare.net/DAssociates/mitigando-fracassos-em-projetos-atravs-da-comunicao-
abordagem-pmi-12974264
O PMBOK, 4ª Edição (2009), traz os processos que são considerados aos de
melhores práticas para a obtenção de uma Definição de Escopo na Gestão de
Projetos, de forma 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 sequenciasequência, 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.
“[...] processos de gerenciamento da integração de projetos, que são:, onde estão inclusos os seguintes processos:”
24
(PMBOK, 2009, p. 71)“4.1 Desenvolver o termo de abertura do projeto - O processo de desenvolvimento de um documento que formalmente autoriza um projeto ou uma fase e a documentação dos requisitos iniciais que satisfaçam as necessidades e expectativas das partes interessadas.”“4.2 Desenvolver o plano de gerenciamento do projeto - O processo de documentação das ações necessárias para definir, preparar, integrar e coordenar todos os planos auxiliares.”“4.3 Orientar e gerenciar a execução do projeto - O processo de realização do trabalho definido no plano de gerenciamento do projeto para atingir os objetivos do projeto.”“4.4 Monitorar e controlar o trabalho do projeto - O processo de acompanhamento, revisão e regulação do progresso para atender aos objetivos de desempenho definidos no plano de gerenciamento do projeto.”“4.5 Realizar o controle integrado de mudanças - O processo de revisão de todas as solicitações de mudança, aprovação de mudanças e gerenciamento de mudanças nas entregas, ativos de processos organizacionais, documentos de projeto e plano de gerenciamento do projeto.
”“4.6 Encerrar o projeto ou fase - O processo de finalização de todas as atividades de todos os grupos de processos de gerenciamento do projeto para terminar formalmente o projeto ou a fase.” (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.
Dos processos que compõem o Capítulo 4, são estudados neste trabalho o
processo 4.1 e o processo 4.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
25
modificado caso o projeto venha a sofrer mudançasalterações, garantindo a
essência do objeto do projeto. Mudanças no TAC (Project Charter), normalmente,
levam ao questionamento de a posição do projeto, se deve continuar ao ser
encerrado e aberto novo projeto.
Ainda navegando pelo PMBOK, 4ª Edição (2009), o Capítulo 5 -captura-se, na
essência, que o Ggerenciamento do escopo do projeto deve descrever 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)
No PMBOK (2009), o Capítulo 5 se propõe e listar as atividades com o conceito das
melhores práticas para o Gerenciamento do Escopo onde pode ser capturado:
“[...] os processos de gerenciamento do escopo do projeto, que inclui o seguinteEste capítulo inclui:: (PMBOK, 2009, p. 103).” (PMBOK, 2009, p. 103).
“5.1 Coletar os requisitos - O processo de definição e documentação das necessidades das partes interessadas para alcançar os objetivos do projeto.”“5.2 Definir o escopo - O processo de desenvolvimento de uma descrição detalhada do projeto e do produto.”“5.3 Criar a EAP - O processo de subdivisão das entregas e do trabalho do projeto em componentes menores e mais facilmente gerenciáveis.”“5.4 Verificar o escopo - processo de formalização da aceitação das entregas terminadas do projeto.”“5.5 Controlar o escopo - O processo de monitoramento do progresso do escopo do projeto e escopo do produto e gerenciamento das mudanças feitas na linha de base do escopo.”
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
26
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: 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 (PMBOK, 2009, p. 10, grifo nosso).
Daso item 2.1.1 cCaracterí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:
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 2-13 ilustra este padrão típico; .
A influência das partes interessadas, os riscos e as incertezas (conforme ilustrado na Figura 2-2)42-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 cada vez menor conforme o projeto progride para o seu término. A Figura 2-24 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). (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.
27
Figura 5 - Nível de custos e pessoal ao longo do ciclo de vidaFonte: PMBOK, 2009, p. 16
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 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)
28
Figura 6 - Impacto da variável com base no tempo decorrido de projetoFonte: PMBOK, 2009, p. 17
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 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)
NDo PMBOK (2009), estudando o item 2.1.2 Relações entre o ciclo de vida do
projeto e do produto, é identificado o texto a seguir que representa o conceito de
múltiplos projetos que, uma vez gerenciados de forma integrada e por um mesmo
GMP pode traduzir efetivos ganhos para a organização, assim tem-se:
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
29
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)
Figura 7 - Fluxo de Atividades (relacionamentos) - PMIFonte: http://blog.mundopm.com.br/wp-content/uploads/2012/03/figura-4.jpg
30
[2.1] DECLARAÇÃO DE ESCOPODeclaração do Escopo
Conforme citado por Vasconcelos et al (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 PMBOK (2009) na FIG. 3, extrai-se que “Ddefinir o escopo é o processo de
desenvolvimento de uma descrição detalhada do projeto e do produto.” (PMBOK,
2009, p. 49). O sucesso do projeto é altamente dependente da declaração do
escopo, devendo esta ser detalhada e fundamentada nas principais entregas,
premissas e restrições, documentadas na iniciação do projeto. O escopo é definido e
descrito com maior qualidade de detalhes, na etapa de planejamento, quando as
informações sobre o projeto vão sendo conhecidas.
As entradas para o processo de definição do escopo segundo o PMBOK (2009) são:
Project Charter ou Termo de abertura do projeto (tradução oficial do PMBOK);
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. Sendo a Atualização dos
documentos do projeto e a Declaração do Escopo as saídas do processo. Na FIG.
36 tem-se o resumo do fluxo básico de influência mútua dentro do procedimento.
(PMBOK, 2009).
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).
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.
31
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 8 -Figura 9 -– Diagrama de fluxo de dados do processo - Definir o escopo
Fonte: PMBOK (2009)
As entradas para o processo de definição do escopo de acordo com o 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.
O termo de abertura do projeto ou Project Charter, segundo o PMBOK (2009), tem a
função de 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
32
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 Gguia 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 (2009) determina como entradas
do processo, 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 FIG. 47, demonsmostra o diagrama de fluxo de dados. (PMBOK
2009).
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.
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.
33
Figura 10 -
Figura 11 - Diagrama de fluxo de dados do processo - desenvolver TAPFonte: (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.” (PMBOK, 2009, p. 75).
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:
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:
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. (PMBOK 2009).
34
“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) (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).
Entre os fatores ambientais que podem afetar o desenvolvimento do Termo de
Abertura do Projeto, o PMBOK (2009) menciona os Padrões governamentais ou
industriais, Infraestrutura organizacional e Condições do mercado, ressaltando que
podem ocorrer outros não citados.
Segundo o PMBOK (2009), os seguintes ativos de processos organizacionais:
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, podem influenciar o processo de desenvolvimento do Termo de
Abertura do Projeto, contudo não se restringem exclusivamente a estes.
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 desenvolvê-lo,
sendo estas aplicadas a todos os detalhes técnicos.
A documentação dos requisitos é definida no PMBOK como:
35
A documentação 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. 109).
“Essa documentação deve retratar o objetivo do projeto, por meio da descrição dos
produtos, serviços e resultados, devendo esses serem completos, mensuráveis e
testáveis e consequentemente documentáveis.”. (XAVIER, 20098, p. 78)
XAVIER (2008) disse “Você pode congelar o escopo de um projeto, mas não as
expectativas do cliente.”. (XAVIER, 20098, p. 87)
Em relação aos ativos de processo organizacionais pelo PMBOK (2009), tem-se:
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. 32).
O Gguia PMBOK (2009), define que declaração do escopo é uma das saídas do
processo para definição do escopo e uma das entradas dos processos para criar a
EAP e 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 referência para o planejamento e monitoramento do projeto,
possibilitando avaliar se as solicitações de mudança ou trabalho adicional fazem
parte do escopo do projeto (PMBOK, 2009).
36
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 a base para um entendimento comum do escopo do
projeto entre os Stakeholders, podendo conter exclusões explícitas do escopo
auxiliando no gerenciamento das expectativas dos mesmos.
A declaração detalhada inclui, seja diretamente ou por referência a outros documentos, o seguinte: (PMBOK, 2009, p. 115-116).
37
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.
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, 2009, p. 115-116).
Ricardo Vargas (2007) 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
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
38
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, 2011, p. 155).
39
POSSI et al. (2006), definem 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: 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, 2006, p. 107)..
Xavier (2009) define a Declaração do escopo como um anteprojeto do escopo de um
projeto. Diz que essa deve fornecer a documentação referencial para a tomada de
decisões e para a confirmação ou desenvolvimento de um entendimento de
consenso do escopo entre as partes envolvidas (Stakeholders). Afirma ainda que
com o progresso do projeto, a declaração do escopo pode necessitar de revisão
para regularizar as mudanças aprovadas devendo conter, 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) (XAVIER, 2008, p.93-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) (XAVIER, 2008, p.95).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;
40
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.
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 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
41
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 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: 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....
42
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).
Segundo XAVIER (2008), a imposição de limite é muito importante, listando as
exclusões do escopo.
43
[2.2] MONITORAMENTO Monitoramento e Controle deo EscopoE 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 (FIG. 8), dos quais dois são
diretamente vinculados às garantias de escopo:
4.4 - Monitorar e controlar o trabalho do projeto
4.5 - Realizar o controle integrado de mudanças
5.5 4 - Verificar o escopo
5.5 - Controlar o Escopo;
6.6 - Controlar o cronograma
7.3 - Controlar os custos
8.3 - Realizar o controle da qualidade
10.5 - Reportar o desempenho
11.6 - Monitorar e controlar os riscos
12.3 - Administrar as aquisições
44
Figura 12
Figura 13 -– - Grupo de processos de mMonitoramento e CcontroleFonte: PMBOK 2009
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, 20094ª Edição, p. 61)
Segundo PMBOK (2009) a verificação do Verificar o eescopo é oé o processo de
formalização da aceitação das entregas concluídas do projeto, in. Incluindo a revisão
das entregas mesmas com o cliente ou patrocinador para assegurar que foram
concluídas satisfatoriamente e obter deles a aceitação formal das mesmasentregas.
A verificação do escopo difere do controle de qualidade, pois está interessada
principalmente na aceitação das entregas, enquanto que o controle de qualidade 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.
45
(PMBOK, 2009, p. 123).
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).
Para controlar o escopo do projeto é preciso 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 monitorar omento do andamento do escopo do
projeto e do produto e o gerenciamento das mudanças feitascometidas na linha de
base do escopo, assegurando . O controle do escopo do projeto assegura qque
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. As mudanças não
controladas são frequentemente chamadas de scope creep. (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).Segundo Coimbra (2012) o
controle do escopo realizado de maneira inadequada tem enorme impacto sobre os
custos do projeto (FIG. 9) sendo um dos principais fatores que podem gerar atrasos
no projeto e alterações no orçamento. As mudanças de escopo nos últimos estágios
de um projeto pode custar até100 vezes a especificação de requisitos.
46
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).
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 incluicompreende a Declaração do escopo do projeto
que incluicontém a descrição do escopo do produto, as entregas do projeto e a
define definição do critério de aceitação do usuário cliente em relação ao produto;,
EAP que: define cada entregas e a decomposição das entregas mesmas em
pacotes de trabalho e o Dicionário da EAP que apresenta: que possui uma d
descrição detalhada do trabalho e documentação técnica para cada elemento da
EAP. (PMBOK, 2009)
47
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)
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)
48
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 (20095), 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 ProjetosXavier (20059), 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 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
49
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 de como o mesmo 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 respectivas 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
requisitos usa-se a mesma metodologia apresentada para Verificação de escopo.
Para ativos de processos organizacionais adota-se os métodos de monitoramento e
50
informação utilizados, políticas, procedimentos e diretrizes existentes, formais ou
informais, relacionadas ao controle do 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 de se adotar 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çõesOs 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. (PMBOK, 2009)
51
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, as
linhas de base dos custos e do cronograma 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.Também a
dDocumentação dos requisitos e Matriz 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 é o direcionamento a condução ddo 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, p. 60) é reconhecida a necessidade de mudança em face de situações
de percurso que assim o exigem:
S “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)
52
[2.3] G estão de Mudanças de Projetos
Pela evolução das incertezas em um projeto, conforme já mostrado na Figura 2-2,
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:
novas tecnologias, decisões governamentais ou mudanças no cenário econômico.
Todas estas 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;
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 e 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
53
projetos. A FIG.igura 108 apresenta uma adaptação do comportamento usual
conforme apontado no trabalho.
Figura 15 - Figura 16 - Resposta humana a situações de mudança
Fonte: Adaptação de Kerzner (2003)
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
54
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.
Kerzner (2003) apresenta um quadro no qual contrabalanceia uma mudança
gerenciada e uma mudança não gerenciada. A Tabela 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 1 - Diferença de esforço e recursos necessários entre mudanças gerenciadas e mudanças não gerenciadas
Fonte: Adaptação de Kerzner (2003)
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.
55
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
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 e 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
56
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 e 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 ao
longo da execução de um projeto. As regras propostas estão descritas a seguir:
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. (COUTINHO; GARCIA, 2012)
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.
57
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 FIG.igura 2-24. Neste gráfico é
possível notar que o 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.
58
2.1 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
59
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.
60
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
61
exigir compensação caso as mudanças sejam oriundas de erros ou decisões da
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
62
a atuação de um gestor de projetos no que tange à gestão das evidências geradas
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
63
parte do gráfico apresentado na Figura 2-2. Neste gráfico é possível notar que o
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.
64
[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.
Segundo a revista Téchne (2013), pode-se identificar atualmente para obras
públicas subterrâneas, que envolvem riscos em razão do método constritivo utilizado
e as condições Geológicas - Geotécnicas do maciço, duas modalidade de contratos
praticadas no mercado e suas variantes, que são contratos do tipo preço unitário
(PU) e contratos do tipo preço global (PG).
Na modalidade preço unitário, é muita utilizada nas licitações públicas, conhecido
internacionalmente como Design - Bid- Built (DBB). Tem como procedimento o
projeto executivo ser elaborado por uma empresa contratada pelo cliente
empreendedor. A licitação é feita com base nas informações deste projeto executivo
e a empresa vencedora do certame é remunerada pelos valores unitários
estabelecidos em sua proposta. Como consequência qualquer alteração de
quantitativo ou no projeto executivo, os riscos da mudança corre por conta do
clientes ou empreendedor, o que reflete no escopo inicial contratado. Segundo
Gómez (2006) citado por Bezerra (2010), nessa modalidade, as empresas
construtoras tinham pouca oportunidade de exercer sua expertise, uma vez que, o
método construtivo já estava definido.
A modalidade DBB evoluiu para Design - Bid- Built – Construction Management
(DBB-CM), após a segunda guerra, nos Estados Unidos, em razão da demanda
crescente da indústria da construção e a busca dos construtores em dividir
responsabilidades. As construtoras executavam o gerenciamento do
empreendimento na fase de execução. “Esse método (DBB-CM- Design - Bid- Built
– Construction Management) começou a ser aplicado no Brasil após o fim do
“Milagre Brasileiro, fim dos anos 70, e ainda é utilizado por algumas empresas
estatais.” (GÓMEZ apud BEZERRA, 2010, p. 2).
65
Na modalidade tipo preço global conhecido internacionalmente como Design - Build
(DB) ou turnkey difere do anterior em razão da elaboração do projeto executivo ser
responsabilidade do construtor, que poderá contratar uma empresa projetista para
fazê-lo. A remuneração da empresa vencedora é realizada por preço fixo, conforme
o avanço do empreendimento, nos termos estipulado no contrato.
Uma terceira modalidade, surgiu em razão da evolução em alguns projetos do
construtor do empreendimento assumir a fase de operação do produto do projeto,
denominada Design - Build – Operate (DBO), onde as características referentes a
construção não difere da modalidade de contratação por preço global (Revista
Techné - 2013). Esta modalidade de contratação (DBO) assemelha-se a modalidade
dos contratos do tipo Parceria Público Privado – PPP.
Segundo Botero (2004) citado por Bezerra (2010, p. 2-3), dentro outras derivativas
da Design - Build (DB) surgiu a modalidade EPC (Engineering, Procurement and
Construction) muito utilizada atualmente.
O projeto básico em qualquer das modalidades de contratação é de
responsabilidade do cliente empreendedor do projeto. Para as modalidades
mencionadas, a exceção do contrato por preço unitário (PU ou DBB), o projeto
básico é de vital importância, já que será a base de informação para a contratação,
portanto, de extrema importância a sua fidedignidade com o objeto e objetivo do
escopo e funcionalidade do produto do projeto.
Na modalidade de contratação do tipo preço unitário o cliente empreendedor, a
empresa projetista e o construtor estabelecem uma relação de três partes
independentes, onde cada parte deve se relacion ar com as outras duas conforme
FIG. 11.
66
Figura 17 - Relações entre as partes em contratos por preço unitário ( PU ou DBB)Fonte: Adaptado da Revista Téchne ,2013, p. 3
Na forma de contratação do tipo Preço Global (PG ou DB) o cliente empreendedor
relaciona apenas com uma parte, que é a entidade executora, formada pela
construtora e suas subcont ratadas, e pela empresa projetis ta conforme FIG. 12.
Figura 18 - Relações entre partes em contratos por preço global (PG ou DB)Fonte: Adaptado Revista Techné, 2013, p. 4
Nessa modalidade, o projet o básico elaborado para a licitação e a contratação é
mais simplificado, sendo fornec idas apenas as diretriz es principais do
empreendimento e as especific ações técnicas e de desempenho relevantes,
deixando para a ent idade exec utora a escolha de mét odos, serviços e
67
materiais, desde qu e o produto final atenda às especific ações técnicas e de
desempenho contratadas (Revista Techné - 2013)
Em termos de relacionamento e comunicação nos contratos do tipo Preço Global
(PG ou DB), umas das principal para cliente empreendedor é o seu único canal
interlocutor é a entidade execut ora, o que simplifica o processo de comunic ação
entre as partes e a administração dos contratos gerenciad os pelo proprietário. Além
disso, o processo de cotação pode ser otimizado no cronograma de
desenvolv imento do empr eendimento, uma vez que, o detalhamento do projeto
básico, que demanda normalmente uma grande parcela de tempo do cronograma,
se rá exec utada pela ent idade exec utora, após a assinatura do contrato. Esses
fatores normalmente reduzem prazos e custos, na fase de contratação do
empr eendimento.
“A f igura a seguir mostra a relação entre os tipos de c ontrato, os graus de risco
correspondentes ao proprietário e à c onstr utora e os custos finais relativos do
empreendimento” (CIRIA, apud REVISTA TECHNÉ, 2013, p.7).
Figura 19 - Relação entre os tipos de contratos e os graus de riscos de custo ( Círia 1978)Fonte: Revista Techné, 2013, p.6
Portanto, pela cima exposto, verifica-se que a modalidade de contratação influencia
no processo de comunicação, relações entre os principais stakeholders, qualidade
das informações de entrada para elaboração da linha de base do escopo e riscos do
projeto.
68
2.2 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 - 683 publicado no site
www.revistatechne.com.br_Engenharia-civil, podemo se 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 relacion ar com
as outras duas conforme figura abaixo:
3 Relatório Técnico nº 99 642-205 - 68, publicado no site www.revistatechne.com.br_Engenharia-civil
69
Figura 20 -Fonte:
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 subcont ratadas, e pela projetis ta conforme figura abaixo:
Figura 21Fonte:
Nessa modalidade, o projet o básico elaborado para a licitação e a contratação é
mais simplificado, sendo fornec idas apenas as diretriz es principais do
empreendimento e as especific ações técnicas e de desempenho relevantes,
deixando para a ent idade exec utora a escolha de mét odos, serviços e
materiais, desde qu e o produto final atenda às especific ações técnicas e de
desempenho contratadas.
70
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 execut ora, o que
simplifica o processo de comunic ação entre as partes e a administração dos
contratos gerenciad os pelo proprietário. Adicionalm ente, o processo de licitação
pode ocorrer mais cedo na escala do tempo de desenvolv imento do
empr eendimento, pois uma parte substancia l d a complementação e detalhamento
do projeto se rá exec utada pela ent idade exec utora, após a adj udicação do
contrato. Esses fatores normalmente reduzem prazos e custos, na fase de pré-
licitação do empr eendimento. Ademais, nessa modalidade é minimizada a
ocorrência de longos e custosos litígios e evitam-se negociações sobre m udanças
nas condições. Outras vantagens decorrem da interação mais ce do da
construtora com a empresa projetista, tais como: apresentaç ão de cont ribuições
ao projet o, identificação e discus são de aspectos de construção etc.
A f igura a seguir mostra a relação entre os tipos de c ontrato, os graus de risco
correspondentes ao proprietário e à c onstr utora e os custos finais relativos do
empreendimento (CIRIA, 1978).
Figura 22Fonte:
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.
71
[2.5] Reequilíbrio Econômico-Financeiro
72
2.3 REEQUILÍBRIO ECONÔMICO-FINANCEIRO
Ferreira e& Guérios (, 2011)4, através do artigo "Função social" e equilíbrio
econômico-financeiro dos contratos, privados e administrativos, expressaramm
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).
Da ideia de “justiça contratual” eclode a condição biunívoca de respeito ao equilíbrio
das cláusulas contratuais em detrimento das pseudo vontades das partes, assim é
possível extrair-se o seguinte:
A análise do direito quanto ao equilíbrio econômico-financeiro dos contratos, quer na
áleas extraordinária dos contratos público, quer dos contratos privados, vêm
mergulhando no conceito de “justiça contratual” e de “função social” (dos contratos),
definições explicitas e implícitas na Carta Magna Brasileira – Constituição Federal de
1988. Tais fundamentos estão similarmente incrustados nos meandros do Código
Civil e, por similitude é possível extrair-se deste os alicerçares para fundamentar ou
repudiar os questionamentos desta ordem.
Como de ser registrado o avanço conceitual que a justiça deu no sentido de verificar
que, apesar de estarem contratados, as partes, muitas vezes, o fizeram em
condições de opressão ou de desvantagem de um em prol do outro, evidentemente,
4 Daniel Ferreira e Patricia B.orges Guérios. Artigo "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.Em: http://www.ambito-juridico.com.br/site/index.php?n_link=revista_artigos_leitura&artigo_id=9548
73
salvaguardadas as questões onde a parte dita em desvantagem assumiu por
conveniência os ônus do contrato com vistas a perspectivas futuras de se locupletar
em função de pleitos premeditados e, assim, vergonhosamente improcedentes.
As questões que definem o pacto contratual coerente e correto fundamenta-se no
conceito da não-hierarquia, ou seja, das condições bilaterais similares e de um
poder de barganha equilibrado entre as partes. Neste cenário é perfeitamente
identificável quando uma das partes, por razões as mais diversas, perde a condição
de equilíbrio econômico-financeiro no pacto contratual e compromete a solvência
dos compromissos assumidos e, quiçá, da continuidade do negócio que detém.
Um novo standard jurídico foi implantado e as questões advindas de cláusulas
contratuais abusivas foram consideradas inócuas e desprezadas quando da análise
do direito das partes, passando-se tais análises para o contexto do pacto bilateral
com direitos e deveres mútuos, equilibrados e coerentes, representando a justiça
contratual pautada na boa fé, sob pena de revisão a qualquer tempo ou demanda.
Basicamente, os contratos firmados dentro dos princípios supra mencionados
podem ser revistos nos casos em que ocorrerem fatos supervenientes,
imprevisíveis, causadores de onerosidade excessiva a uma das partes, cujo impacto
tem dimensão suficiente para destruir a relação inicialmente pactuada, vindo ao
encontro da “justiça social”. Tal não pode nem deve ser flertado no caso de uma das
partes de forma consciente, mesmo que inconsequente, tenha assumido riscos
elevados sem a devida retaguarda para cobrir eventuais prejuízos destes risco,
sendo assim o único responsável pela assunção da própria desídia.
Em virtude da justiça contratual, o contrato em sua formação e execução deverá respeitar o equilíbrio entre as prestações e um equilíbrio global entre os direitos e as obrigações que cabem a cada uma das partes, atuando como limite à autonomia da vontade. Cada parte, além de receber o equivalente ao que deu, não pode estar submetida a obrigações desproporcionais, dentro da economia global do contrato, buscando-se não o equilíbrio ideal, mas o mínimo que restaure a proporcionalidade inicialmente existente. (FRANZ, 2007, p. 30).
A prestação de serviços e a respectiva contraprestação da parte contratante,
obrigatoriamente têm de estar sintonizadas no equilíbrio bilateral, com a
74
equivalência entre os deveres e obrigações com fulcro no meio mercadológico que
certa o objeto contratual.
75
A justiça contratual, assim, passa a incorporar um conteúdo qualitativamente diverso: fala-se em justiça comutativa, de modo que o dirigismo contratual atuará para buscar o equilíbrio da relação contratual. Admite-se, pois a revisão do pactuado quando houver desequilíbrio da equação econômico-financeira do contrato no curso de sua execução. Se no contrato clássico o princípio da pacta sunt servanda era quase absoluto, na nova ordem principiológica ele é relativizado, abrindo espaço para a cláusula rebus sic standibus, reputada como ínsita a todos os contratos. Deslegitima-se, por conseguinte, a ideia de Fouillée, de matriz Kantiana, de que “quem diz contratual diz justo. (RUZYK, 2002, p. 31)
Considerando as diferenças entre os contratos privados e os contratos
administrativos, há de ser observado que os segundos admitem as chamadas
cláusulas exorbitantes (do direito privado) em condições personalíssimas que assim
o requeiram o interesse público, não mais que isto.
Importa destacar, de conseguinte, que tanto os contratos privados como os contratos basicamente regidos pelo direito administrativo[15] devem observar o princípio da justiça contratual como condição de validade, o que pode reclamar, para melhor compreensão, uma brevíssima reflexão acerca das diferenças existentes entre ambos. Naqueles a igualdade é pressuposta, de sorte que há de haver uma perfeita harmonia entre os deveres de um em relação aos do outro, o mesmo se dizendo em relação aos direitos; nestes, há um aparente desequilíbrio, “tolerado” com fundamento no interesse público. (FERREIRA; GUÉRIOS, 2011).
Romeu Felipe Bacellar Filho et al. (2004), invocando a função social do contrato
define os limites do que é tolerável e do que é o estrito espaço do rigor da lei a que
estão submetidos os administradores públicos, não sendo tolerados caprichos ou
desatinos por parte destes sob pena de incorrerem em sérios desvios de conduta.
O contrato administrativo não se liberta, porém, de algumas características próprias a qualquer avença, insista-se, da categoria contrato. Como consectário de uma obrigação, o contrato resulta de um acordo de vontades. A autonomia, temperada pela função social do contrato, constituiu elemento imprescindível a ser observado em qualquer avença. Do mesmo modo, os princípios Lex inter partem e pacta sunt servanda fazem certo que o contrato é a lei entre as partes e que estas, devidamente ajustadas, devem observar o que foi pactuado. Neste passo mostra-se evidente que o instrumento do contrato há de sujeitar-se aos ditames da lei, companheira inseparável do administrador contratante, sempre em prospectiva coletiva e que as obrigações contratadas também haverão de postar-se submissas ao conjunto normativo. Afinal, ao administrador não se lhe confere nenhuma liberdade, antes, um espaço de atuação dentro da lei. (BARCELAR at al., 2004, p. 320).
Na Constituição da República, conforme depara-se no inciso XXI, do art. 37 com a
questão do equilíbrio econômico - financeiro do contrato administrativo, tem-se:
76
XXI - ressalvados os casos especificados na legislação, as obras, serviços, compras e alienações serão contratados mediante processo de licitação pública que assegure igualdade de condições a todos os concorrentes, com cláusulas que estabeleçam obrigações de pagamento, mantidas as condições efetivas da proposta, nos termos da lei, o qual somente permitirá as exigências de qualificação técnica e econômica indispensáveis à garantia do cumprimento das obrigações.
Abstrai-se do referido dispositivo que o equilíbrio da equação econômico-financeira é
considerado elemento essencial do contrato administrativo, por ser mecanismo apto
a manter as condições efetivas da proposta, constitucionalmente garantido ao
particular contratado quando ocorrer risco de prejuízo por eventos futuros, incertos e
excepcionais. Portanto trata-se de uma característica essencial do contrato
administrativo reconhecida pela própria Constituição no art. 37, inciso XXI (“mantidas
as condições efetivas da proposta”), não podendo ser elidida quando o caso atender
ao exigido pela lei.
No que pertine ao tema, interessante colacionar conceitos proferidos por ilustres
doutrinadores. Celso Antônio Bandeira de Mello assim assevera:
[...] o equilibro econômico financeiro é a relação de igualdade formada, de um lado, pelas obrigações assumidas pelo contratante no momento do ajuste e, de outro lado, pela compensação econômica que lhe corresponderá. (MELLO, 2012. p. 347)
No mesmo diapasão Hely Lopes Meirelles menciona:
O equilíbrio financeiro ou equilíbrio econômico, ou equação econômica, ou ainda equação financeira do contrato administrativo é a relação estabelecida inicialmente pelas partes entre os encargos do contratado e a retribuição da Administração para a justa remuneração do objeto do ajuste. Essa relação encargo-remuneração deve ser mantida durante toda a execução do contrato, a fim de que o contratado não venha a sofrer indevida redução nos lucros normais do empreendimento. (MEIRELLES, 2013, p. 209).
Acerca da mesma matéria, Marçal Justen Filho expõe:
Uma vez verificado o rompimento do equilíbrio econômico-financeiro, o particular deve provocar a Administração para adoção das providências adequadas. Inexiste discricionariedade (...). Deverá examinar-se a situação originária (à época da apresentação das propostas e a posterior. Verificar-se-á se a relação original entre encargos e remuneração foi afetada. Em caso positivo, deverá alterar-se a remuneração do contratado proporcionalmente à modificação dos encargos. (JUSTEN FILHO, 2000, p. 551).
Existe direito do contratado de exigir o restabelecimento do equilíbrio econômico-financeiro do contrato, se e quando viera a ser rompido. Se os
77
encargos forem ampliados quantitativamente ou tornados mais onerosos qualitativamente, a situação inicial estará modificada. (...) Significa que a administração tem o dever de ampliar a remuneração devida ao particular proporcionalmente à majoração dos encargos verificada. Devendo-se restaurar a situação originária, de molde que o particular não arque com encargos mais onerosos e perceba a remuneração originalmente prevista. Ampliado os encargos, deve-se ampliar proporcionalmente a remuneração. A regra foi expressamente consagrada no art. 58,§ 2º, a propósito de modificação unilateral do contrato, mas se aplica a qualquer evento que afete a equação econômico-financeira. (JUSTEN FILHO, 2000, p. 556).
Registra-se, outrossim, julgado do Tribunal de Contas da União pertinente ao
equilíbrio econômico-financeiro do contrato:
Equilíbrio econômico-financeiro. Contrato. Teoria da Imprevisão. Alteração Contratual. A ocorrência de variáveis que tornam excessivamente onerosos os encargos do contratado, quando claramente demonstradas, autorizam a alteração do contrato, visando ao restabelecimento inicial do equilíbrio econômico financeiro, com fundamento na teoria da imprevisão, acolhida pelo Decreto-Lei 2.300/86 e pela atual Lei n.º 8.666/93. (TCU, TC-500.125/92-9, Min. Bento José Bugarin, 27/10/94, BDA n.º 12/96, Dez/96, p. 834).
“Como a utilidade coletiva é pressuposta, tanto nos contratos de direito privado
como nos administrativos, sempre que possível a solução intermediária, de
recomposição (do equilíbrio econômico-financeiro), há de ser privilegiada.”
(FERREIRA; GUÉRIOS, 2011).
Para situações limítrofes e para as demandas cujo teor gere conflitos insolúveis,
pode provocar a dissolução dos pactos contratuais pode ser o último rito, podendo
afirmar-se:
“A eventual resolução do contrato, como medida de prestação jurisdicional, pode
apenas servir para amainar os ânimos egoísticos das partes contratantes, o que não
necessariamente reflete o interesse coletivo que dele (do contrato) se pode extrair.”
(FERREIRA; GUÉRIOS, 2011).
78
Para fechar este item, faz-se registrar a conclusão de Ferreira e Guérios (2011):
A recomposição da equação econômico-financeira dos contratos administrativos pode e deve, sempre que possível, ser implementada por meio de um processo interno, instaurado ex officio ou a pedido. Do mesmo modo, nada obsta que os contratos de direito privado sejam revistos, a pedido de uma ou de ambas as partes, para restauração da justiça contratual. Aliás, hipótese como essa apenas confirmaria a boa-fé objetiva recíproca, ainda quando presente desequilíbrio na relação contratual. (FERREIRA; GUÉRIOS, 2011).
79
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 Sergio Luiz Gomes Santiago
MONITORAMENTO E CONTROLE DE ESCOPO
Marlene Maria Franciscoco. de Oliveira
GESTÃO DE MUDANÇAS DE PROJETOS Carlos Henrique Loyola
GERENCIAMENTO DE ESCOPO – VARIANTES EM FUNÇÃO DO TIPO DE
CONTRATORogério Márcio Galantine
REEQUILÍBRIO ECONÔMICO-FINANCEIRO Carlos Fernando de Albuquerque
Derivada diretamente da questão primária da definição de escopo com todas as
nuances que necessitam estar explicitas para se ter um plano de projeto adequado e
com as menores chances de sofrerem mudanças, a avalanche de pleitos em
contratos administrativos e, quiçá, em contratos privados, passa pela etapa inicial de
todo projeto, a Declaração de Escopo, ou seja, o contratante tem de definir ao
detalhe o que realmente deseja e como deseja receber o objeto do contrato - todo o
arcabouço do objeto, com premissas, restrições, etc... Dentre estes tópicos, no
segmento de obras, o Brasil esta algumas décadas atrasado, onde ainda estamos
na época do esboço servindo de base para contratar e não de um projeto executivo
bem elaborado e detalhado, com memoriais completos, orçamento realmente
representativo do que se tem por executar e em que condições, plano de obra
(ataque a obra), dentre outros. Países do chamado 1º mundo, levam 2/3 do tempo
do projeto para projetar e planejar o que vão erigir, e 1/3 para efetivamente
materializar o objeto do projeto.
80
É fático, frente ao que é vivenciado nas proposições de pleitos (claims), que o
administrador deve dispor primeiro no papel (eletrônico, claro, e em 3D,
preferencialmente) aquilo que deseja, promovendo os ajustes e acertos que os
stakeholders entenderem como o melhor para a finalidade última do objeto. Dado
com conclusas as etapas de projetos, esgotando-se as possíveis variantes, com a
aprovação de todos os envolvidos em uma maratona de meetings para obterem-se
as aprovações, parte-se para o planejamento e, enfim, para as obras de fato. No
Brasil, via de regra, projetos são considerados elementos custosos e não é dado o
valor devido a estes, contratando-se pelo menor preço e não pela capacidade e
capacitação de execução do projetista, assim, tem-se projetos de baixíssima
qualidade, com orçamentos derivados destes que, ainda por cima, são elaborados
de maneira mecânica, invariavelmente por profissionais de baixa capacitação para
tal, sem vínculo com a realidade do ambiente onde será instalado, tanto do ponto de
vista da realidade da obra (complexidade), quanto dos elementos periféricos
(ambiente regional) que influenciam significativamente os custos, os modos
operacionais, toda a logística e outros.
É uma verdadeira tragédia grega o ambiente vivenciado pela gestão de contratos
derivados de projetos incompletos e orçamentos idem, condição que nos leva a
questão do excesso de pleitos em vários contratos aventada por diversos
administradores públicos e, até, privados, quando se deparam com as construtoras
se preocupando mais em analisar os “furos” de orçamento, de projeto e, por que
não, dos próprios Editais (Termos de Referência no meio). Tal ocorre, pois este
conjunto de documentos, muitas vezes, não se inter-relaciona de forma harmônica e
não estão suficientemente completos para expressar o real desejo do administrador
ou as reais necessidades que o objeto necessita atender, desta forma, muito há que
se evoluir na mentalidade dos administradores para que a execução do objeto
transcorra sem maiores percalços.
É fundamental o entendimento de que os custos com os projetos são abruptamente
menos custosos, por mais elaborados que sejam, do que obras executadas de forma
equivocadas e/ou sob uma gestão constante de mudanças, fato que deriva para
uma indeterminação dos custos e prazos dos contratos, conforme Kerzner (2011).
81
82
3.1 DECLARAÇÃO Declaração deo EscopoDE 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).
83
[3.1] MONITORAMENTO Monitoramento e Controle deo EscopoE 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
ocorrerapresentando propostas para controlar as respectivas..
É 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.
84
[3.2] GESTÃO Gestão de Mudanças de ProjetosDE 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.
85
[3.3] GERENCIAMENTO DE ESCOPO – Variantes em Função do Tipo de ContratoARIANTES 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.
86
[3.4] REEQUILÍBRIO Reequilíbrio Econômico-Financeiro
A análise do direito quanto ao equilíbrio econômico-financeiro dos contratos, quer na
áleas extraordinária dos contratos público, quer dos contratos privados, vêm
mergulhando no conceito de “justiça contratual” e de “função social” (dos contratos),
definições explicitas e implícitas na Carta Magna Brasileira – Constituição Federal de
1988. Tais fundamentos estão similarmente incrustados nos meandros do Código
Civil e, por similitude é possível extrair-se deste os alicerçares para fundamentar ou
repudiar os questionamentos desta ordem.
Como de ser registrado o avanço conceitual que a justiça deu no sentido de verificar
que, apesar de estarem contratados, as partes, muitas vezes, o fizeram em
condições de opressão ou de desvantagem de um em prol do outro, evidentemente,
salvaguardadas as questões onde a parte dita em desvantagem assumiu por
conveniência os ônus do contrato com vistas a perspectivas futuras de se locupletar
em função de pleitos premeditados e, assim, vergonhosamente improcedentes.
As questões que definem o pacto contratual coerente e correto fundamenta-se no
conceito da não-hierarquia, ou seja, das condições bilaterais similares e de um
poder de barganha equilibrado entre as partes. Neste cenário é perfeitamente
identificável quando uma das partes, por razões as mais diversas, perde a condição
de equilíbrio econômico-financeiro no pacto contratual e compromete a solvência
dos compromissos assumidos e, quiçá, da continuidade do negócio que detém.
Um novo standard jurídico foi implantado e as questões advindas de cláusulas
contratuais abusivas foram consideradas inócuas e desprezadas quando da análise
do direito das partes, passando-se tais análises para o contexto do pacto bilateral
com direitos e deveres mútuos, equilibrados e coerentes, representando a justiça
contratual pautada na boa fé, sob pena de revisão a qualquer tempo ou demanda.
Basicamente, os contratos firmados dentro dos princípios supra mencionados
podem ser revistos nos casos em que ocorrerem fatos supervenientes,
imprevisíveis, causadores de onerosidade excessiva a uma das partes, cujo impacto
tem dimensão suficiente para destruir a relação inicialmente pactuada, vindo ao
87
encontro da “justiça social”. Tal não pode nem deve ser flertado no caso de uma das
partes de forma consciente, mesmo que inconsequente, tenha assumido riscos
elevados sem a devida retaguarda para cobrir eventuais prejuízos destes risco,
sendo assim o único responsável pela assunção da própria desídia.ECONÔMICO-
FINANCEIRO
EQUILÍBRIO ECONÔMICO-FINANCEIRO DO CONTRATO ADMINISTRATIVO
Na Constituição da República, conforme depara-se no inciso XXI, do art. 37 com a
questão do equilíbrio econômico - financeiro do contrato administrativo, tem-se:
XXI - ressalvados os casos especificados na legislação, as obras, serviços, compras e alienações serão contratados mediante processo de licitação pública que assegure igualdade de condições a todos os concorrentes, com cláusulas que estabeleçam obrigações de pagamento, mantidas as condições efetivas da proposta, nos termos da lei, o qual somente permitirá as exigências de qualificação técnica e econômica indispensáveis à garantia do cumprimento das obrigações.
Abstrai-se do referido dispositivo que o equilíbrio da equação econômico-financeira é
considerado elemento essencial do contrato administrativo, por ser mecanismo apto
a manter as condições efetivas da proposta, constitucionalmente garantido ao
particular contratado quando ocorrer risco de prejuízo por eventos futuros, incertos e
excepcionais. Portanto trata-se de uma característica essencial do contrato
administrativo reconhecida pela própria Constituição no art. 37, inciso XXI (“mantidas
as condições efetivas da proposta”), não podendo ser elidida quando o caso atender
ao exigido pela lei.
No que pertine ao tema, interessante colacionar conceitos proferidos por ilustres
doutrinadores. Celso Antônio Bandeira de Mello assim assevera:
[...] o equilibro econômico financeiro é a relação de igualdade formada, de um lado, pelas obrigações assumidas pelo contratante no momento do ajuste e, de outro lado, pela compensação econômica que lhe corresponderá. (MELLO, 2012. p. 347)
No mesmo diapasão Hely Lopes Meirelles menciona:
O equilíbrio financeiro ou equilíbrio econômico, ou equação econômica, ou ainda equação financeira do contrato administrativo é a relação estabelecida inicialmente pelas partes entre os encargos do contratado e a retribuição da Administração para a justa remuneração do objeto do ajuste. Essa relação encargo-remuneração deve ser mantida durante toda a execução do contrato, a fim de que o contratado não venha a sofrer indevida redução nos lucros normais do empreendimento. (MEIRELLES, 2013, p. 209).
88
Acerca da mesma matéria, Marçal Justen Filho expõe:
Uma vez verificado o rompimento do equilíbrio econômico-financeiro, o particular deve provocar a Administração para adoção das providências adequadas. Inexiste discricionariedade (...). Deverá examinar-se a situação originária (à época da apresentação das propostas e a posterior. Verificar-se-á se a relação original entre encargos e remuneração foi afetada. Em caso positivo, deverá alterar-se a remuneração do contratado proporcionalmente à modificação dos encargos. (JUSTEN FILHO, 2000, p. 551).
Existe direito do contratado de exigir o restabelecimento do equilíbrio econômico-financeiro do contrato, se e quando viera a ser rompido. Se os encargos forem ampliados quantitativamente ou tornados mais onerosos qualitativamente, a situação inicial estará modificada. (...) Significa que a administração tem o dever de ampliar a remuneração devida ao particular proporcionalmente à majoração dos encargos verificada. Devendo-se restaurar a situação originária, de molde que o particular não arque com encargos mais onerosos e perceba a remuneração originalmente prevista. Ampliado os encargos, deve-se ampliar proporcionalmente a remuneração. A regra foi expressamente consagrada no art. 58,§ 2º, a propósito de modificação unilateral do contrato, mas se aplica a qualquer evento que afete a equação econômico-financeira. (JUSTEN FILHO, 2000, p. 556).
Registra-se, outrossim, julgado do Tribunal de Contas da União pertinente ao
equilíbrio econômico-financeiro do contrato:
Equilíbrio econômico-financeiro. Contrato. Teoria da Imprevisão. Alteração Contratual. A ocorrência de variáveis que tornam excessivamente onerosos os encargos do contratado, quando claramente demonstradas, autorizam a alteração do contrato, visando ao restabelecimento inicial do equilíbrio econômico financeiro, com fundamento na teoria da imprevisão, acolhida pelo Decreto-Lei 2.300/86 e pela atual Lei n.º 8.666/93. (TCU, TC-500.125/92-9, Min. Bento José Bugarin, 27/10/94, BDA n.º 12/96, Dez/96, p. 834).
“Como a utilidade coletiva é pressuposta, tanto nos contratos de direito privado
como nos administrativos, sempre que possível a solução intermediária, de
recomposição (do equilíbrio econômico-financeiro), há de ser privilegiada.”
(FERREIRA; GUÉRIOS, 2011).
Para situações limítrofes e para as demandas cujo teor gere conflitos insolúveis,
pode provocar a dissolução dos pactos contratuais, podendo afirmar-se:
“A eventual resolução do contrato, como medida de prestação jurisdicional, pode
apenas servir para amainar os ânimos egoísticos das partes contratantes, o que não
89
necessariamente reflete o interesse coletivo que dele (do contrato) se pode extrair.”
(FERREIRA; GUÉRIOS, 2011).
90
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).
91
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).
92
6 REFERÊNCIAS BIBLIOGRÁFICAS
ARAÚJO, Wladmir. Apresentação Gerenciamento De Projetos com PMBOK e FEL. Disponível em: <http:// www.slideshare.net/wladmir_araujo/gerenciamento-de- projetos-com-pmbok-e-fel.> Aacesso em: 22 mar.. 2013.
BARCAUI, André. PMO: Escritório de Projetos, Programas e Portfólio na prática. Rio de Janeiro: Brasport, 2012.
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. Disponível em <http:// info.ucsal.br/banmon/Arquivos/Mono3_0131.pdf .> aAcesso em: dia mês ano22 mar. 2013.
BRITO, Ilmário Rocha - A importância da gestão de escopo em projetos. Disponível em: <http:// www.techoje.com.br/site/techoje/categoria/detalhe_artigo/406 .> aAcesso em: dia16 mar.ço 2013 mês 2008.
COIMBRA, Rodrigo - Monitoramento e Controle: Controlar o Escopo Disponível em http:// projetoseti.com.br/gestao/gerencia-de-projetos-pmp/gp-escopo/ monitoramento-e-controle-controlar-o-escopo/. >Aacesso em: 23 mar.ço 2013
COUTINHO, Ítalo; GARCIA, Edson. Pleitos em Projetos Industriais: gestão de registros. 2012. Disponível em: <http:// www.techoje.com.br/site/techoje/categoria/detalhe_artigo/1218 .> Acesso em: dia mês 201222 mar. 2013.
DUARTE, Aline et al. Implantação do Gerenciamento de Mudanças de Escopo. Belo Horizonte: IETEC, 2009.
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. Disponível em: <www.ambito-juridico.com.br/site/index.php?n_link=revista_artigos_leitura&artigo_id=9548.> Acesso em: dia mês 2011.: 22 mar. 2013.
KERZNER, H. - Gerenciamento de Projetos: Uma Abordagem Sistêmica para Planejamento, Programação e Controle. 10ª Ed. São Paulo: Blucher, 2011.
KERZNER, Harold. Project Management: A System Approach to Planning, Scheduling and Controlling. Eighth Edition. New Jersey: Hoboken, 2003.
KERZNER, Harold; SALADIS, Frank P. - Gerenciamento de Projetos Orientado por Valor. Porto Alegre: Artmed Editora, 2009.
MERIGUETTI, Cézar; DINSMORE, P - Mitigando Fracassos em Projetos através da Comunicação: abordagem PMI. Disponível em:
93
<http:// www.slideshare.net/DAssociates/mitigando-fracassos-em-projetos-atravs-da- comunicao-abordagem-pmi-12974264>. Acesso em: dia mês 2012.: 22 mar. 2013.
MULCAHY, Rita; DIETHELM, Laurie. Preparatório para o exame de PMP. 7ª Ed. EUA, Ed. RMC Publications, 2011.
POSSI, Marcus et al. Gerenciamento de Projetos: Guia do Profissional Vol. 3: Fundamentos Técnicos. Ecthos/Brasport, 2006.
Project Management Institute. Um guia do Conjunto de Conhecimentos em Gerenciamento de Projetos (Guia PMBOK) - 4ª Edição. Pennsylvania: PMI, 2009.
Revista Techne. Disponível em:<www.revistatechne.com.br/engenharia-civil/136/imagens/Relatorio_5.1.pdf>. Acesso em: 22 mar. 2013dia mês ano
SANTOS, Diogo Nei. Apresentação – 10 Dicas para Definir o Escopo do Projeto. Disponível em: <papogp.com/2009/05/26/10-dicas-para-definir-o-escopo-do-projeto/http:// papogp.com/2009/05/26/10-dicas-para-definir-o-escopo-do-projeto/ >, 2009,. Acesso em: dia mês 200926 março 2013.
VALERIANO, D. L.., Gerência de Projetos: Pesquisa, Desenvolvimento e Engenharia. São Paulo: Makron Books, 2002.
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.
VARGAS, Ricardo Viana. Gerenciamento de Projetos: Estabelecendo Diferenciais Competitivos. 3ª Ed. Rio de Janeiro:, Brasport, 2007.
XAVIER, Carlos Magno. - Gerenciamento de Projetos: - Como definir e controlar o escopo do projeto. São Paulo: Editora Saraiva, 20095.
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.
94
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. Disponível em: 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.
FRANZ, Laura Carodani. Revisão dos contratos. São Paulo : Saraiva, 2007. VARGAS, Ricardo Viana. Gerenciamento de Projetos – Estabelecendo Diferenciais Competitivos. 3ª Ed. Ver. Rio de Janeiro, Ed. Brasport, 2007.
MULCAHY, Rita; DIETHELM, Laurie. Preparatório para o exame de PMP. 7ª Ed. EUA, Ed. RMC Publications, 2011.
RUZYK, Carlos Eduardo Pianowski. Os princípios contratuais: da formação liberal à noção contemporânea. In: RAMOS, Carmem Lúcia Silveira (Org.). Direito civil constitucional: situações patrimoniais. Curitiba : Juruá, 2002.
BACELLAR FILHO, Romeu Felipe. Contrato administrativo. In: BACELLAR FILHO, Romeu Felipe (coord. geral); MOTTA, Paulo Roberto Ferreira. CASTRO, Rodrigo Pironti Aguirre de (coords.). Direito administrativo contemporâneo: estudos em memória do professor Manoel de Oliveira Franco Sobrinho. Belo Horizonte: Editora Fórum, 2004.
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.
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.
95
ATENÇÃO: Faltando a quantidade de PÁGINAS de cada LIVRO que deve ser
registrada ao final de cada referencia.