Como uma pergunta aparentemente simples — «De quem é este trabalho?» — expõe a verdadeira maturidade da OBS,
da WBS e do EVMS.
1.1 A pergunta que ninguém quer fazer na reunião
Em quase todos os projetos complexos chega o momento em que alguém,
normalmente num tom irritado, pergunta:
«Afinal, de quem é este trabalho?»
Não estamos a falar de quem ajuda ou de quem foi copiado no e-mail.
Falamos de qual entidade na OBS é
A (Accountable)
e qual entidade é
R (Responsible)
por aquela parte do escopo. Pessoas individuais (CAM, superintendente,
chefe de equipa) representam esses nós da OBS, mas o A/R vive
primeiro na estrutura organizacional.
A
OBS
existe para responder, de forma inequívoca, a essa pergunta — e para que
a resposta seja a mesma na engenharia, na construção, no controlo de projeto,
no contrato e no Dono da Obra.
1.2 Entregas, escopo e dinheiro: o triângulo invisível
O escopo técnico vive na
WBS.
Cada nó WBS representa uma entrega ou um grupo coerente de entregas:
um tanque de armazenamento, um sistema de drenagem de pista, uma unidade de ureia-granulada.
O dinheiro vive em contratos, orçamentos e
contas de controlo (Control Accounts, CAs)
.
É na CA que o EVMS mede custo, prazo e desempenho de cada parte significativa do escopo.
A responsabilidade vive na OBS. Cada nó representa uma entidade:
um departamento interno do Dono da Obra, o consórcio EPC, um subempreiteiro de terraplenagem,
a equipa de comissionamento, a camada independente OICAL.
A Lei
WBS sem OBS é catálogo de entregas. OBS sem WBS é organograma decorativo.
Só quando WBS, OBS e contas de controlo se cruzam é que passa a existir controlo real.
1.3 Porque é que isto falha tanto em projetos reais
Em projetos de LNG, aeroportos ou fertilizantes, vemos o mesmo padrão:
WBS com boas entregas, mas sem ligação clara a contas de controlo.
OBS desenhada como organograma de RH, em vez de mapa de entidades A/R.
EVMS configurado por obrigação contratual, sem testar se alguém
consegue apontar A e R para cada CA.
O resultado é familiar: cronogramas e orçamentos que parecem técnicos,
mas que na prática ninguém consegue defender quando o Dono da Obra pergunta
«Quem é A? Quem é R?».
Anti-padrão clássico
O projeto tem um PMO cheio de dashboards, mas quando a drenagem de pista atrasa,
ninguém sabe se a responsabilidade está na equipa de terraplenagem,
na de drenagem ou no subempreiteiro de pavimentos. A OBS não responde.
Capítulo 2
De entregas (WBS) a entidades (OBS): ligar escopo e responsabilidade
Como transformar uma WBS orientada a entregas numa OBS que distribui A/R de forma clara,
sem perder a lógica de controlo de custos e prazos.
2.1 O que a WBS faz bem — e o que não consegue fazer sozinha
A WBS é o sítio certo para organizar o escopo do projeto:
entregas físicas, sistemas, edifícios, pacotes de engenharia.
Em projetos de LNG, isto traduz-se em unidades de processo, sistemas de utilidades,
tanques de armazenamento, offsites, exportação, etc.
Numa expansão de aeroporto, a WBS tem entregas como:
Terraplenagem e plataformas (zonas de corte e aterro).
Pistas, taxiways e pátios de estacionamento.
Sistema de drenagem e bacias de retenção.
Terminal de passageiros, bagagens, parque de estacionamento.
Para uma unidade de ureia-amoníaco, surgem entregas como:
unidade de amoníaco, unidade de ureia, granulação, utilidades fora de bateria de processo,
área de carga e descarregamento ferroviário.
Tudo isto é excelente para ver escopo, mas não responde à pergunta:
quem é A? quem é R? A WBS não sabe quem é Dono da Obra, quem é EPC,
quem é subempreiteiro ou PMC. Ela só sabe o que tem de existir no fim:
as entregas.
2.2 A e R como entidades na OBS, não como pessoas soltas
Na
OBS,
cada nó representa uma entidade responsável por parte do escopo:
um contrato EPC, um subempreiteiro de drenagem, a Direção de Operações do Dono da Obra,
o PMC, a equipa OICAL.
Quando falamos em
A (Accountable)
estamos a falar de um nó da OBS, não de uma pessoa individual.
Da mesma forma,
R (Responsible)
é o nó que executa ou coordena o trabalho, mesmo que no terreno isso
se manifeste através de supervisores, encarregados e equipas.
Em termos de EVMS, o nó A da OBS em cada CA é normalmente
representado por um
CAM (Control Account Manager)
.
O CAM é a pessoa; a unidade A é a entidade (contrato, equipa, departamento)
que aparece na OBS e que assume o escopo dessa conta de controlo.
2.3 Onde WBS e OBS se cruzam: contas de controlo e work packages
O ponto em que WBS e OBS se encontram é a
conta de controlo (Control Account, CA)
.
Cada CA representa um pedaço relevante do escopo (nó WBS)
entregue por uma entidade A/R (nó OBS).
Abaixo da CA vivem os
work packages (WPs), onde o
escopo é fatiado em unidades de trabalho que as equipas no terreno reconhecem:
campanhas de terraplenagem, fases de montagem mecânica,
pacotes de cablagem, testes de sistemas, etc.
Ponto de amarração
Cada CA deve ter:
(1) um nó WBS claro (qual é a entrega ou grupo de entregas),
(2) um nó A da OBS,
(3) pelo menos um nó R da OBS,
(4) um CAM nomeado que represente o A e coordene os WPs.
2.4 Exemplo rápido: drenagem de pista num aeroporto
Imagine um projeto de aeroporto em que a WBS tem:
WBS 1.2.1 — Drenagem da pista principal.
WBS 1.2.2 — Pavimentação da pista principal.
A OBS tem, entre outros nós:
OBS-EPC-CIV — EPC Civil & Estruturas.
OBS-SUB-DREN — Subempreiteiro de drenagem.
OBS-SUB-PAV — Subempreiteiro de pavimentação.
OBS-PMC-AIR — PMC Airside.
OBS-OICAL — OICAL (camada independente de controlo).
Uma boa configuração de CA poderia incluir:
CA-DRN-01: Drenagem da pista principal — WBS 1.2.1 × OBS-SUB-DREN
(A = OBS-EPC-CIV, R = OBS-SUB-DREN).
CA-PAV-01: Pavimentação da pista principal — WBS 1.2.2 × OBS-SUB-PAV
(A = OBS-EPC-CIV, R = OBS-SUB-PAV).
O PMC e o OICAL aparecem como C (Consulted) e I (Informed) na
matriz RACI, mas não são A nem R dessas CAs — ajudam a controlar,
não a executar o escopo.
A Lei
Se um atraso não consegue ser mapeado para uma CA com A/R claros,
o problema não é só de cronograma. É de desenho de OBS e de contas de controlo.
Capítulo 3
Desenhar a OBS para um Empreiteiro EPC
Como transformar o organograma de um EPC numa OBS que distribui A/R sobre o escopo certo — e não apenas cargos de RH.
3.1 EPC como titular do EVMS
Neste cenário, o
Empreiteiro EPC
é o titular do
EVMS.
É no EPC que vivem a maior parte das
contas de controlo (CAs)
e dos work packages. O Dono da Obra recebe relatórios e audita,
mas o modelo de A/R sobre o escopo vive essencialmente na OBS do EPC.
Se a OBS do EPC for apenas um organograma funcional (Direção de Engenharia,
Direção de Construção, etc.), as CAs acabam por ficar demasiado grandes,
difusas e difíceis de ligar a equipas concretas no terreno.
3.2 Eixos para desenhar a OBS do EPC
Uma OBS útil para controlo cruza, tipicamente, alguns eixos:
Áreas / unidades (tanques, utilidades, process units, pista, terminal).
Contratos-chave (JV interno, consórcio, grandes subempreiteiros principais).
O erro clássico é tentar misturar três ou quatro eixos em simultâneo
no mesmo nível da OBS, criando nós impossíveis de gerir. Em vez disso,
escolhe-se um eixo dominante por nível — por exemplo:
primeiro unidades/áreas, depois disciplinas, depois subdivisões por fase.
3.3 Nós A e R típicos no EPC
Em cada parte relevante do escopo, o EPC precisa de pelo menos dois nós na OBS:
Um nó
A (Accountable)
, normalmente uma
equipa de área ou uma superintendência.
Um ou mais nós
R (Responsible)
, como subequipas de disciplina, frentes de obra ou grandes
subempreiteiros coordenados pelo EPC.
Cada CA aponta para o nó A da OBS e, quando necessário, para um nó R
distinto. O CAM é a pessoa que
representa o nó A — mas o A vive na OBS, não no organograma de pessoas.
3.4 Anti-padrões na OBS do EPC
OBS = organograma de RH
Nós como «Diretor de Construção» ou «Chefe de Obra» aparecem duas
ou três vezes em áreas diferentes, criando confusão sobre quem é
A/R para cada parte do escopo.
OBS só por disciplina
Nós como «Tubagem», «Eléctrico» e «Civil» sem referência a áreas
levam a CAs gigantes, misturando tanques, pipe-racks e edifícios
na mesma unidade de medição.
A Lei
Se não consegues apontar uma frente de obra no terreno e dizer
«esta frente é A/R deste nó da OBS», a tua OBS é apenas um
organograma decorativo.
Capítulo 4
Da OBS do EPC às contas de controlo e work packages
Como transformar uma OBS bem desenhada em CAs e work packages que as equipas reconhecem
— e que suportam um EVMS credível.
4.1 Regra básica: CA = WBS × OBS
Cada conta de controlo representa a interseção entre:
um nó WBS — «qual entrega ou grupo de entregas?»
um nó A da OBS — «qual entidade é accountable (A)?»
A partir daí podemos registar custo, prazo, quantidades e desempenho
para esse bloco de escopo. Se uma CA junta várias entregas sem
coerência (WBS fraca) ou várias entidades A (OBS confusa),
o EVMS perde significado.
4.2 Tamanho saudável de uma CA
Não há regra única, mas alguns critérios práticos para CAs do EPC:
Escopo claro: a equipa no terreno consegue descrever
que entregas estão dentro da CA sem hesitar.
Duração controlável: tipicamente 3–6 meses de trabalho,
com marcos intermédios que se refletem no cronograma.
Valor material: suficientemente grande para importar
no orçamento, mas não tão grande que o desvio seja impossível de tratar.
Work packages mais pequenos vivem dentro da CA, ligados ao
planeamento de detalhe (por exemplo, pacotes de montagem de tubagem
por isométrico ou por linha).
CA = WBS × OBS: cada conta de controlo cruza um nó de escopo na WBS com um nó A/R na OBS;
os work packages vivem dentro dessa mesma CA e reportam ao respetivo nó A.
4.3 Work packages que as equipas reconhecem
Um work package (WP) útil é uma unidade de trabalho
que uma equipa de campo reconhece como tarefa concreta: uma campanha
de estacas, uma frente de tubagem num pipe-rack, um conjunto de cabos
num corredor de cablagem.
No contexto de
AWP (Advanced Work Packaging)
,
os WPs do EVMS podem alinhar-se com
CWPs e
IWPs,
desde que a ligação à CA seja clara: cada CWP/IWP deve viver
dentro de uma CA e reportar para um nó A da OBS.
4.4 O que destrói o EVMS: CAs artificiais
Exemplo: CA "Miscelânea de tubagem GTP"
Para simplificar, alguém cria uma CA genérica que junta tubagem de
várias áreas, com R em equipas diferentes e A pouco definido.
Quando a tubagem atrasa numa área crítica, o desvio dilui-se e o
sistema deixa de avisar a tempo.
A Lei
Uma CA nunca deve existir apenas porque é «conveniente» para o
software. Deve existir porque representa um cruzamento real entre
escopo (WBS) e entidade A/R (OBS) que interessa controlar.
Capítulo 5
Quando o Dono da Obra é o titular do EVMS
Como desenhar a OBS do Dono da Obra quando é este que detém o EVMS e consolida desempenho
de EPC, subempreiteiros, PMC e OICAL.
5.1 Porque é que o Dono da Obra precisa da sua própria OBS
Mesmo quando o EPC tem o seu próprio EVMS, o
Dono da Obra precisa de uma OBS própria para:
definir quem é A/R por cada parte do escopo do ponto de vista do Dono;
integrar vários contratos (EPC, infraestrutura externa,
serviços de operação, etc.);
gerir contas de controlo de
custos internos
,
que não vivem em nenhuma OBS de empreiteiro.
A OBS do Dono da Obra não substitui a do EPC — complementa-a. Em muitas CAs,
a entidade A na OBS do Dono será, por exemplo, «Direção de Projeto LNG»,
enquanto na OBS do EPC o A será «Superintendência de Tanques».
Contratos externos: EPC principal, contratos de infraestruturas,
contratos de logística e operações, etc.
Extensões do Dono da Obra: PMC, equipas de comissionamento do Dono,
equipas de HSE corporativas.
A partir destes eixos, definem-se nós A/R que vão aparecer na matriz de
responsabilidades
RACI
e nas CAs que vivem no lado do Dono.
5.3 CAs em que o Dono da Obra é A
Exemplos de contas de controlo típicas no lado do Dono da Obra:
CA-OWN-PMO — Gestão global do projeto (planeamento, relatórios, governação).
CA-OWN-COMM — Comissionamento do Dono da Obra (equipa interna).
CA-OWN-OPER — Preparação de operações (procedimentos, formação, readiness reviews).
Nestes casos, a WBS pode referir-se a entregas como «Plano de
Comissionamento», «Manual de Operação», «Base de Dados de TAGs»,
enquanto a OBS aponta para equipas internas ou extensões como PMC.
A Lei
Mesmo quando o EPC tem um EVMS forte, o Dono da Obra precisa da sua
própria OBS e das suas próprias CAs para tudo aquilo que ninguém
mais pode fazer por ele.
Capítulo 6
EPC como R num ambiente multi-parte
O que muda na OBS quando o EPC deixa de ser o titular único do EVMS e passa a ser
sobretudo R em contas de controlo lideradas pelo Dono da Obra.
6.1 Firewall saudável entre Dono da Obra e EPC
Num ambiente multi-parte, o Dono da Obra pode ter CAs próprias que
consolidam desempenho de vários contratos. O EPC, por seu lado,
continua a ter o seu EVMS interno. É crucial definir um
firewall de governação:
onde termina a CA do EPC e começa a CA do Dono;
que dados de EV são partilhados e com que atraso;
como são tratadas diferenças entre baseline do EPC e baseline do Dono.
A OBS ajuda a tornar isto explícito: na CA do Dono da Obra, o EPC
aparece como R; na CA interna do EPC, a entidade A é uma equipa do EPC.
Pilha de responsabilidade A/R/C/I: o Dono da Obra assume A em sistemas-chave, o EPC assume R de execução,
subempreiteiros são R subordinados, e PMC/OICAL aparecem tipicamente como C ou I, não como A nem R.
6.2 RAM multi-parte
A matriz de responsabilidades
RAM passa a ter
vários níveis:
RAM interna do EPC — liga WBS do EPC à OBS do EPC.
RAM do Dono da Obra — liga WBS global à OBS do Dono, incluindo nós
que representam EPC, subempreiteiros, PMC e OICAL.
Em cada linha (entrega ou sistema), a RAM mostra qual entidade A/R
do Dono e qual entidade A/R do EPC. Quando isto é claro, disputas sobre
«quem devia ter visto este risco» diminuem drasticamente.
6.3 O que quebra a confiança
Exemplo: baseline paralelos
O EPC mantém um cronograma e CAs internas; o Dono da Obra mantém
outro. As OBSs não estão alinhadas, os códigos de CA não batem
certo, e cada atraso é discutido como se fosse um facto alternativo.
A Lei
Não há EVMS multi-parte sem uma linguagem comum de OBS, WBS e CAs.
Cada parte pode ter o seu sistema, mas todos têm de falar dos
mesmos nós quando discutem A/R.
Capítulo 7
OBS de subempreiteiros: até onde modelar
Quando vale a pena descer a OBS até subempreiteiros individuais — e quando isso apenas complica sem melhorar o controlo.
7.1 Subempreiteiros como nós da OBS
Alguns subempreiteiros são suficientemente críticos para aparecerem
como nós explícitos na OBS: terraplenagem massiva, tanques de grande
diâmetro, pipeline offsite, data center, etc. Noutros casos, o EPC
pode preferir tratar vários subempreiteiros como parte de um único
nó R mais agregado.
A decisão deve basear-se em:
impacto em caminho crítico e risco de atraso;
valor financeiro e exposição contratual;
necessidade de visibilidade específica para o Dono da Obra.
7.2 Quando modelar demasiado fundo é um erro
Se cada pequeno fornecedor ou micro-empreiteiro virar um nó na OBS,
a RAM torna-se ilegível e o esforço de manter o modelo ultrapassa o
benefício. Em vez de clarificar A/R, cria-se ruído.
Regra prática
Só modelar subempreiteiros individuais como nós OBS quando:
(1) têm escopo claramente identificável na WBS,
(2) a sua falha isolada pode comprometer marcos importantes,
(3) existe necessidade explícita de visibilidade no nível do Dono.
7.3 Ligação às contas de controlo
Quando um subempreiteiro aparece como nó na OBS, isso deve refletir-se
nas CAs e no EVMS. Exemplos:
CA-TANK-01 — Tanque de MEG — A = EPC-Tanques, R = Sub-Tanques-X.
CA-RUNWAY-DRN — Drenagem pista principal — A = EPC-Civil, R = Sub-Drenagem-Y.
Em ambos os casos, o subempreiteiro é um nó R; o EPC continua A e
mantém um CAM interno responsável pela CA perante o Dono da Obra.
Capítulo 8
PMC e OICAL como extensões do Dono da Obra
Onde encaixam PMC e OICAL na OBS e na RAM — e como evitar que confundam a pergunta «De quem é o trabalho?».
8.1 PMC: braço operacional do Dono da Obra
O
PMC
normalmente aparece como nó na OBS do Dono da Obra, muitas vezes
como R em tarefas ligadas a planeamento, relatórios e fiscalização,
enquanto a Direção de Projeto do Dono mantém A.
Exemplo de RAM:
Entrega «Relatório Mensal de Progresso»: A = Dono-PM, R = PMC.
Entrega «Plano Integrado de Cronograma»: A = Dono-PM, R = PMC.
8.2 OICAL: camada independente
A função
OICAL
é diferente: não é apenas mais um R; é uma camada de
verificação independente que valida dados de
progresso, riscos, custos e previsões.
Na RAM, o OICAL é tipicamente C (Consulted) ou I (Informed) em
muitas entregas e A/R em entregas próprias, como «Relato independente
de controlo» ou «Auditoria EVMS».
PMC vs OICAL: o PMC ajuda a gerir escopo, prazo e custo em nome do Dono da Obra; o OICAL é a camada
independente de verificação. Uma firewall de governação evita que a mesma entidade marque e corrija os seus
próprios testes.
8.3 O perigo de tornar PMC ou OICAL "donos" do escopo
Anti-padrão
Em alguns projetos, o PMC ou o OICAL acabam por ser tratados como
A de escopo que pertence ao EPC ou a equipas internas do Dono da
Obra. Resultado: todos assumem que «alguém» está a tratar do
problema, mas ninguém tem A/R real sobre a entrega.
A Lei
PMC e OICAL aumentam a qualidade da decisão — mas não podem
substituir A/R do escopo principal. Se um nó PMC ou OICAL aparece
como A numa entrega de construção, algo está errado na OBS.
Capítulo 9
Trabalho contínuo, governação e OBS sem WBS leaf
Como tratar na OBS e nas contas de controlo o trabalho que não está ligado a uma entrega única:
governação, reuniões, relatórios e suporte contínuo.
9.1 Trabalho que nunca acaba mas precisa de A/R
Nem todo o trabalho do projeto se traduz numa entrega física clara.
Exemplos:
reuniões semanais de coordenação interdisciplinar;
gestão de mudanças, gestão de riscos, reporting;
governação de contratos, análise de claims, suporte jurídico.
Este trabalho nem sempre tem um WBS leaf clássico, mas
precisa na mesma de nós A/R na OBS e, muitas vezes,
de contas de controlo para custo e esforço.
9.2 CAs de governação e suporte
Em vez de forçar estes tópicos para dentro de CAs técnicas (tanques,
pista, unidades de processo), é preferível criar CAs específicas,
com entregas mais abstratas mas bem definidas:
CA-GOV-01 — Governação de Projeto e Comités de Decisão.
CA-RISK-01 — Gestão de Riscos Integrada.
CA-REP-01 — Relatórios de Progresso e Dashboards.
O escopo destas CAs é definido em termos de serviço
contínuo, não de entregas únicas: cadência de reuniões,
qualidade de informação, prazos de decisão.
9.3 Porque isto é crítico para a fiabilidade do cronograma e do EV
O trabalho de governação e suporte é muitas vezes visto como
«overhead» e por isso mal modelado. Mas é precisamente aí que se
decide:
se riscos são tratados cedo ou tarde demais;
se pedidos de mudança são avaliados com dados sólidos;
se o EVMS é visto como ferramenta de decisão ou mera formalidade.
Quando estas funções têm CAs claras e A/R explícitos na OBS, torna-se
possível medir o esforço investido e discutir se a governação é
suficiente ou insuficiente para o tamanho do projeto.
A Lei
Trabalho contínuo sem A/R explícitos é terreno fértil para
surpresas. Se governação, risco e reporting não têm lugar claro
na OBS e nas CAs, o projeto perde previsibilidade quando mais
precisa dela.
PARTE IV
OBS nos Dados, nas Ferramentas e nos Relatórios
Transformar a OBS, as Contas de Controlo e os Pacotes de Trabalho em tabelas reais,
ligadas ao cronograma, ao orçamento e ao BI — de forma simples, auditável e reutilizável.
Capítulo 10
Do Desenho Conceptual ao Modelo de Dados
Como sair dos quadros brancos e dos diagramas para chegar a tabelas concretas de OBS, CA,
WP e RAM que podem viver em Excel, P6, ferramentas de custo e Power BI.
10.1 As quatro tabelas-mãe
Uma OBS só passa a existir “de verdade” quando está em tabelas. Na prática, precisa no
mínimo de quatro:
Tabela OBS_Registry — uma linha por entidade da OBS
(unidades de A/R),
com código, nome, tipo e entidade-pai.
Tabela CA_Register — uma linha por Conta de Controlo, ligando
CA_ID ao WBS (entregas/escopos) e à OBS
(OBS_A, OBS_R).
Tabela WP_Register — uma linha por Pacote de Trabalho, filho de uma CA,
com quantidades, datas-alvo e entidade de execução
(OBS_R).
Tabela RAM_Matrix — matriz CA × OBS onde marcamos A/R/C/I
para cada combinação relevante.
Ponto-chave
Se uma entidade OBS, uma Conta de Controlo ou um Pacote de Trabalho não aparece numa
tabela, essa responsabilidade não existe para o sistema de controlo —
mesmo que todos falem dela nas reuniões.
10.2 Campos mínimos que não podem faltar
Para cada tabela, há um “mínimo viável” de campos:
OBS_Registry
OBS_Code – código estável, curto.
OBS_Name – nome claro da entidade.
OBS_Type – p.ex. Dono da Obra, EPC, Sub, PMC, OICAL.
Parent_OBS – ligação hierárquica.
Is_Leaf – se pode receber A/R ou não.
CA_Register
CA_ID – código da Conta de Controlo.
Scope_Ref_Type – tipo de referência de escopo
(entrega WBS, sistema, área, serviço contínuo).
Scope_Ref_ID – ID da entrega/escopo de referência.
OBS_A – entidade A (Accountable).
OBS_R – entidade R (Responsável pela execução).
EV_Method – 0/100, por quantidade, por marco, etc.
Da mesma forma, a tabela de WP precisa pelo menos de
WP_ID, CA_ID,
datas planeadas, quantidade planeada e entidade
OBS_R. A matriz RAM precisa de
CA_ID, OBS_Code e
um campo com o papel (A, R, C ou I).
10.3 Ligar OBS, CA e WP ao cronograma e ao orçamento
Depois das tabelas, o passo seguinte é ligar tudo aos sistemas que mandam no dia-a-dia:
Cronograma (P6, MSP, etc.) — cada atividade ligada a um
CA_ID e a uma entidade
OBS_R. É assim que a equipa de campo vê
“qual é o meu trabalho hoje” num contexto de OBS.
Orçamento e custo — cada linha de custo ou recurso
(contrato, PO, equipa interna) ligado à CA e à OBS, para que variações
de custo possam ser explicadas por entidade A/R.
Gestão de risco — riscos-chave (p.ex. atrasos de OFI, interfaces)
ligados às CAs relevantes e às entidades que têm de atuar.
Lei
Se o código OBS ou o código de Conta de Controlo não aparecer no cronograma e no
sistema de custos, a OBS deixa de ser “espinha dorsal” e volta a ser apenas um desenho.
Capítulo 11
OBS em Painéis, Relatórios e BI
Como usar a OBS para ver a realidade do projeto: desempenho por entidade, variações por
Conta de Controlo e alertas que chegam às mãos de quem pode agir.
11.1 Vistas mínimas que todo projeto deveria ter
Quando a OBS está bem ligada às CAs e aos Pacotes de Trabalho, é relativamente simples
produzir vistas que mudam o comportamento:
Desempenho por entidade A — gráfico onde cada linha é uma entidade
OBS_A, mostrando SPI, CPI e tendência de previsão por conta.
Desempenho por entidade R — foco no lado que executa, permitindo ver
quais equipas de campo estão sistematicamente atrasadas ou adiantadas.
Mapa de responsabilidades — lista de CAs com problemas, ordenada por
variação de prazo ou custo, com o respetivo A e R claramente visíveis.
Oficinas de recuperação — relatórios preparados por CA e por entidade
R, que servem de base a reuniões de recuperação de escopo.
11.2 Erros de BI que destroem a utilidade da OBS
Alguns erros são muito comuns:
Dashboards só por disciplina — mostram “Tubagens”, “Civil”, “Elétrica”
mas não mostram quem (que entidade OBS) é responsável por cada parte.
Gráficos por contrato sem ligação a CAs — dificultam a ligação entre
problemas de desempenho e entregas específicas do WBS.
Relatórios que só veem pessoas, não entidades — “João”, “Maria”,
“Chefe de Projeto”, sem referência à equipa ou unidade OBS de que fazem parte.
Falta de filtros por Dono da Obra / EPC / Sub / PMC / OICAL —
cada parte precisa de se ver a si própria e aos outros, sem misturar papéis.
Mau padrão
Se o painel de controlo do projeto não conseguir responder rapidamente à pergunta
“quais entidades A/R estão a causar mais desvio neste mês?”, a OBS não está a
alimentar o BI de forma correta.
11.3 Boas práticas para relatórios baseados em OBS
Um único registo-mestre — o código e o nome da OBS vêm sempre da
tabela OBS_Registry, nunca de textos digitados à mão.
Filtros claros por papel — permitir filtrar por OBS_A, OBS_R,
Dono da Obra, EPC, Sub, PMC, OICAL.
Snapshots mensais — guardar versões mensais das tabelas de CA e WP
para permitir auditorias e análises de tendência.
Comentários ancorados a CAs — notas de risco, decisões e ações
associadas sempre a uma Conta de Controlo específica.
Lei
Um dashboard que não “fala OBS” não é um dashboard de controlo — é apenas um
gráfico bonito. A OBS tem de estar presente em todos os filtros e legendas que
importam.
PARTE V
Governação, Auditorias e Aprendizagem com a OBS
Manter a OBS e o modelo de CA/WP saudáveis ao longo da vida do projeto, aprender com
falhas reais e deixar modelos reutilizáveis para o próximo contrato.
Capítulo 12
Governação e Auditoria da OBS & do EVMS
Como garantir que a OBS não é apenas um documento inicial, mas um sistema vivo de
responsabilização, com auditorias simples que qualquer equipa consegue passar.
12.1 Fundamentos de governação
A primeira regra é simples: alguém tem de ser dono do modelo.
Normalmente precisamos de:
Um custodiante de OBS/EVMS do Dono da Obra e um
custodiante de OBS/EVMS do EPC, responsáveis por códigos, regras e
integridade de dados.
Processo de controlo de alterações — qualquer mudança a nós OBS,
CAs ou WPs passa por pedido, revisão de impacto e aprovação formal.
Histórico e versionamento — tabelas com campos de data de início e
fim de validade, ou registos de versões guardados mensalmente.
Reuniões periódicas de “higiene” — para eliminar códigos mortos,
alinhar nomenclaturas e tratar de incoerências entre sistemas.
12.2 Disciplina A/R e papel dos CAMs
A e R são entidades da OBS, não pessoas individuais. Ainda assim,
é preciso uma pessoa que represente a entidade A em cada Conta de Controlo:
o Control Account Manager (CAM).
A entidade A responde pelo resultado global daquele escopo:
datas-chave, custo, qualidade, integração com outros sistemas.
A entidade R é responsável pela execução diária:
equipas, turnos, métodos e sequência de trabalho.
O CAM é a pessoa que representa a entidade A perante o sistema de
controlo — mas continua a ser a entidade A (p.ex. “EPC-PIPING-CONST”) que aparece
nas tabelas e relatórios.
Erro frequente
Tratar A e R como nomes de pessoas e não como entidades OBS leva a discussões
intermináveis (“mas esse engenheiro já saiu do projeto”) e destrói a continuidade
dos dados entre fases.
12.3 Auditorias que testam a realidade, não o papel
Uma boa auditoria não começa pelo Excel; começa pelo campo. Exemplos de testes simples:
Escolha uma Conta de Controlo aleatória e pergunte qual é a entidade A e a entidade R.
Se as equipas hesitam, o modelo não está interiorizado.
Pegue num Pacote de Trabalho e vá até à frente de obra. A descrição é reconhecida
pela equipa que está a trabalhar naquele local?
Selecione um atraso real (p.ex. testes de um sistema elétrico) e tente traçar quem
é A e quem é R, desde o Dono da Obra até ao subempreiteiro.
Lei
Uma OBS que não consegue sobreviver a uma auditoria de corredor
— “olha para esta CA e diz-me quem manda aqui” — não é um sistema de controlo.
É decoração.
Capítulo 13
Estudos de Caso e Padrões de Falha
Casos realistas em projetos de LNG, aeroportos e fertilizantes que mostram como erros de
OBS acabam em atrasos, reclamações e conflitos políticos.
13.1 Atraso em tanques de LNG
Um projeto de LNG sofre um atraso de nove meses para colocar o parque de tanques
em condições de armazenamento. A análise de causa-raiz revela:
Escopo de tanques dividido em três CAs vagas e sobrepostas.
Nenhuma entidade OBS claramente responsável (A) por “Tanques LNG” como um todo —
havia várias equipas parcelares.
Fornecedores, civil e mecânica não apareciam na RAM com papéis A/R/C/I explícitos.
Quando a OBS é redesenhada com uma equipa de Tanques bem definida e entidades de
subempreiteiros explicitadas, o segundo tanque progride de forma previsível e as
disputas encolhem.
13.2 Pista e drenagem num aeroporto
Num aeroporto, pavimentos de pista e taxiways começam a falhar pouco depois da
entrada em serviço. A investigação mostra que o sistema de drenagem estava atrasado
e incompleto quando o pavimento foi executado.
A OBS tinha apenas um nó “Civil Airside”; a CA tratava todo o lado ar como uma única
Conta de Controlo. Depois da restruturação:
CAs distintas para drenagem, terraplenagens e pavimentos.
Equipas OBS separadas com papéis A/R claros, incluindo o Dono da Obra para
aprovações de janela de fecho da pista.
PMC e OICAL com papéis C explícitos, obrigados a registar objeções e recomendações.
13.3 Corredor de exportação de fertilizantes
Uma fábrica de fertilizantes entra em operação mas não consegue exportar ao ritmo
planeado. Silos, correias transportadoras e instalações marítimas eram geridos por
equipas diferentes, sem uma CA de “Corredor de Exportação” que unisse tudo.
Ao criar uma CA de Corredor de Exportação, com um nó A do Dono da Obra para Logística
e um nó R do EPC para “Offsites & Marine”, além de entradas RAM para autoridade portuária
e empreiteiro marítimo, as decisões e programas de recuperação tornam-se coerentes.
Lei
Sempre que um problema atravessa meia dúzia de contratos e ninguém sabe
“quem é A” pelo resultado global, falta uma CA e um nó OBS para esse sistema.
Capítulo 14
Exercícios, Perguntas e Modelos Prontos
Para pôr a teoria em prática: exercícios de desenho, perguntas didáticas com respostas
escondidas e modelos de Excel que pode adaptar ao seu projeto.
14.1 Exercícios de desenho
Exercício 1 — OBS de um aeroporto
A partir de um WBS simplificado (terraplenagens, pista, taxiways, terminal,
bagagens, utilidades), desenhe uma OBS para o EPC e atribua entidades A/R para
três CAs críticas.
Exercício 2 — OBS de uma fábrica de ureia e amoníaco
Com base num WBS de amoníaco–ureia–utilidades, desenhe as OBS do Dono da Obra
e do EPC e construa uma RAM para o sistema de granulação de ureia.
14.2 Perguntas de revisão com respostas escondidas
Use estas perguntas para testar se a OBS, as Contas de Controlo e os Pacotes de
Trabalho do seu projeto estão saudáveis. Clique em cada pergunta para ver a resposta.
Pergunta 1. Qual é a diferença entre organograma e OBS?
Resposta. O organograma mostra pessoas, hierarquias formais e
linhas de reporte. A OBS mostra entidades que assumem responsabilidade A/R sobre
escopos e entregas — equipas, contratos, unidades funcionais. A OBS é o que entra
nas tabelas de CA e WP; o organograma não.
Pergunta 2. Porque é perigoso tratar A e R como nomes de pessoas?
Resposta. Pessoas saem do projeto; entidades OBS ficam.
Se A/R forem nomes de pessoas, os dados históricos tornam-se ilegíveis e é
impossível analisar desempenho por equipa. A entidade A/R deve ser sempre um
nó OBS; as pessoas são representantes (CAM, supervisores) dessa entidade.
Pergunta 3. O que torna uma Conta de Controlo “boa”?
Resposta. Uma boa CA liga um pedaço coerente de escopo
(entrega ou serviço contínuo) a um único A e a um conjunto pequeno de R,
tem quantidades mensuráveis, marcos claros e é suficientemente grande para
interessar à gestão, mas pequena o bastante para ser gerida por um CAM.
Pergunta 4. O que acontece se uma CA cobrir simultaneamente três sistemas críticos?
Resposta. Fica impossível dizer qual sistema está a causar
o desvio; a equipa de campo deixa de se reconhecer nas medições e as ações de
recuperação viram generalidades (“mais horas”, “mais equipa”) em vez de medidas
focadas por sistema.
Pergunta 5. Quando é que precisa de CAs para trabalho contínuo (reuniões, relatórios, supervisão)?
Resposta. Sempre que o esforço é relevante para o orçamento
e crítico para a previsibilidade do projeto. PMO, supervisão de campo,
comissionamento, OICAL — tudo isso merece CAs próprias, mesmo que não esteja
ligado a uma entrega WBS única.
Pergunta 6. Porque é que “um CA por contrato” costuma ser uma má ideia?
Resposta. Contratos abrangem frequentemente múltiplos escopos
e áreas. Um único CA por contrato mistura realidades diferentes, esconde problemas
em zonas críticas e torna impossível comparar desempenho por sistema ou área.
Pergunta 7. Como é que uma OBS mal codificada estraga previsões de prazo e custo?
Resposta. Se códigos OBS forem inconsistentes, duplicados ou
instáveis, o BI deixa de conseguir acumular dados por entidade. SPI, CPI e
tendências deixam de ser comparáveis entre meses e projetos, o que torna
as previsões altamente voláteis e pouco credíveis.
Pergunta 8. Porque é que uma CA deve ter exatamente um CAM?
Resposta. Vários CAMs por CA diluem a responsabilidade e
criam desculpas (“pensei que o outro estava a tratar”). Um único CAM por CA
evita zonas cinzentas e torna claro quem representa a entidade A nas decisões
de prazo, custo e recuperação.
Pergunta 9. Quando faz sentido que A e R sejam a mesma entidade OBS?
Resposta. Em escopos pequenos, executados integralmente pela
mesma equipa (p.ex. um pacote de estudos de engenharia interno). Em trabalhos
complexos, separar A (quem responde pelo resultado) de R (quem executa)
ajuda a clarificar a cadeia de responsabilização e os conflitos de prioridade.
Pergunta 10. Que sinal mostra que Subempreiteiros não estão modelados corretamente na OBS?
Resposta. Sempre que problemas recorrentes com um subempreiteiro
aparecem em relatórios apenas como “Civil” ou “Mecânica”, sem código OBS próprio,
e não é possível ver o desempenho desse sub ao longo das CAs em que atua.
Pergunta 11. Como distinguir, na RAM, o papel do PMC e do OICAL?
Resposta. PMC normalmente aparece como R ou C em atividades de
gestão de projeto, coordenação e supervisão; OICAL aparece como C em CAs de
controlo e como A em CAs específicas de “independent assurance”. Misturar os
papéis quebra a independência.
Pergunta 12. O que é uma auditoria “walk-through” da OBS e porque é poderosa?
Resposta. É um teste simples: pegar numa CA, perguntar quem é A
e R, ir até ao campo e verificar se as equipas se reconhecem no pacote de
trabalho. Se este exercício falhar, não é preciso relatórios complexos para
concluir que o modelo está frágil.
Pergunta 13. Como é que OFI (Owner-Furnished Items) deve aparecer na OBS?
Resposta. Como entidades próprias: equipa de Aquisições do Dono
da Obra, gestão de OFI, gestão de itens de longo prazo. Essas entidades aparecem
como A ou R em CAs específicas; caso contrário, qualquer atraso de OFI vira
discussão interminável entre Dono da Obra e EPC.
Pergunta 14. Porque é importante ter CAs para “integração de sistemas”?
Resposta. Muitos atrasos surgem nos interfaces: entre processo e
utilidades, entre pista e navegação aérea, entre fábrica e porto. Sem CAs
específicas para integração, ninguém é claramente A por fazer estes sistemas
funcionarem em conjunto.
Pergunta 15. Que risco existe em criar CAs novas a meio do projeto sem controlo?
Resposta. A história de desempenho é partida em pedaços,
linhas base ficam difíceis de reconstruir e os relatórios deixam de ser
comparáveis entre meses. Qualquer nova CA ou divisão de CA deve seguir um
processo formal de alteração.
Pergunta 16. O que um gráfico SPI/CPI por entidade A deve disparar numa reunião mensal?
Resposta. Três perguntas simples: quais entidades A estão
sistematicamente abaixo de 1,0? Que CAs explicam esses valores? Que ações
concretas foram acordadas com os respetivos CAMs? Sem isto, o gráfico é apenas
decoração estatística.
Pergunta 17. Como usar a OBS para mitigar conflitos de “culpa” entre Dono da Obra e EPC?
Resposta. Modelar CAs específicas para OFI, aprovações do Dono
da Obra, decisões de janela de shutdown, etc., onde o Dono da Obra aparece como A
ou R. Assim, atrasos ficam ancorados em CAs concretas, em vez de discussões vagas
sobre “apoio do cliente”.
Pergunta 18. Em que momento um projeto deve congelar a estrutura alta da OBS?
Resposta. Tipicamente ao fim da fase de definição de CAs
(baseline de EVMS). A partir daí só se ajustam folhas da OBS, sem mexer nas
grandes entidades (Dono da Obra, EPC, grandes subs, PMC, OICAL), evitando
reescrever a história do projeto.
Pergunta 19. Qual é o impacto de não ter RAM formal?
Resposta. As discussões de responsabilidade ficam baseadas em
memória, e-mails antigos e interpretações de contrato. A RAM torna explícito
quem é A, R, C e I por CA; sem ela, qualquer conflito sério tende a parar em
reclamações e arbitragens.
Pergunta 20. Que pergunta simples você pode fazer para saber se a OBS está a ajudar o projeto?
Resposta. Pergunte a um supervisor de campo: “Quando algum
problema aparece no cronograma ou no relatório de custo, você consegue ver
rapidamente qual é a sua parte (R) e quem é o A acima de si?” Se a resposta for
“não”, a OBS ainda não chegou ao terreno.
Pergunta 21. O que acontece quando as atividades do cronograma não estão ligadas às CAs e às entidades OBS_R?
Resposta. O cronograma deixa de “falar a mesma língua” que o EVMS. SPI e CPI passam a ser números abstratos, porque não se consegue ver quais atividades concretas (e quais equipas R) estão a gerar o desvio. Reuniões de prazo transformam-se em debates genéricos (“estamos atrasados em civil”) em vez de discussões focadas por Conta de Controlo e por entidade R. Sem esta ligação, o cronograma não consegue suportar previsões fiáveis nem planos de recuperação credíveis.
Pergunta 22. Como é que o mau uso de trabalho de Esforço Contínuo (LOE) pode destruir a leitura do EV?
Resposta. Quando quase tudo é modelado como LOE, o EV cresce “por tempo” e não por progresso real de entregas. SPI e CPI ficam sempre perto de 1,0, mesmo quando tanques, pistas ou unidades de processo estão atrasados. LOE deve ser reservado para CAs de governação e suporte (PMO, EVMS, OICAL), com limites claros; para escopos físicos, as CAs devem usar critérios discretos (quantidades, marcos, testes) para que o EV reflita de facto o avanço das entregas.
Pergunta 23. Quais são os riscos de copiar uma OBS “de template” de outro projeto sem adaptação séria?
Resposta. Uma OBS reciclada pode ignorar escopos críticos específicos (p.ex. exportação marítima num projeto de fertilizantes ou ORAT num aeroporto) e criar entidades A/R que não existem na estrutura real do contrato. Isto gera CAs órfãs, conflitos de fronteira entre equipas e relatórios que ninguém reconhece no terreno. Templates são úteis como ponto de partida, mas cada projeto precisa de uma revisão profunda de OBS, CAs e RAM à luz do seu WBS, contratos e riscos próprios.
Pergunta 24. Como começar a corrigir a OBS e as CAs num projeto já em curso, sem “rebentar” o EVMS?
Resposta. O caminho mais seguro é atuar por ondas: primeiro, congelar a OBS de alto nível e identificar 5–10 CAs críticas onde a estrutura atual está a gerar confusão; depois, redesenhar apenas essas CAs (e respetiva RAM) com regras claras de alteração e datas de efeito. Em paralelo, manter um mapa de equivalência entre CAs antigas e novas para preservar a história do EV. A correção gradual, ancorada em problemas reais de prazo e custo, melhora a fiabilidade das previsões sem destruir a rastreabilidade do projeto.
14.3 Modelos sugeridos
Alguns ficheiros que vale a pena manter no seu repositório de padrões:
OBS_Registry.xlsx — códigos, nomes, tipo, entidade-pai e indicador de folha.
CA_Register.xlsx — CA_ID, tipo e ID de referência de escopo, OBS_A, OBS_R, método de EV.
WP_Register.xlsx — WP_ID, CA_ID, entidade OBS_R, quantidades planeadas e datas.
RAM_Matrix.xlsx — matriz CA × OBS com papéis A/R/C/I.
Lei
Não espere pela “ferramenta perfeita” para modelar a sua OBS e as CAs. Comece com
tabelas simples — à medida que o projeto cresce, tudo o resto acaba por gravitar em
torno delas.
