Entenda MIDP e TIDP em profundidade: ISO 19650-2, task teams, EIR, BEP, information containers, marcos, dependências, CDE, LOIN, aceite e controle das entregas BIM.
Confira!
MIDP e TIDP são instrumentos de planejamento das entregas de informação utilizados na lógica da ISO 19650-2 para transformar requisitos de informação em compromissos executáveis. O TIDP — Task Information Delivery Plan — organiza as entregas de um task team; o MIDP — Master Information Delivery Plan — integra e coordena os diferentes TIDPs em uma visão mestre das entregas necessárias ao projeto.
Essa distinção parece administrativa, mas tem efeito direto sobre coordenação, prazo e risco. Um projeto pode possuir EIR, BEP, cronograma, CDE e equipes tecnicamente competentes e ainda falhar porque ninguém traduziu os requisitos em uma sequência coerente de information containers, responsáveis, marcos, dependências, revisões e autorizações. Quando isso acontece, a informação chega tarde, incompleta ou sem condição de uso.
MIDP e TIDP devem, portanto, ser tratados como parte do sistema de planejamento e controle do projeto. Eles conectam requisitos contratuais, produção técnica, task teams, CDE, coordenação, LOIN, model checking e marcos de decisão. Seu valor não está em manter uma planilha atualizada, mas em tornar visível se a informação necessária estará disponível antes da atividade que depende dela.
A ISO 19650-2:2018 continua sendo a edição publicada vigente em 2026, confirmada em 2024. Há uma nova edição em desenvolvimento, ainda em estágio de Draft International Standard. Para contratos, procedimentos e auditorias, a referência deve continuar sendo a edição publicada aplicável, sem transformar conteúdo de draft em requisito normativo vigente.
MIDP e TIDP: o que realmente está sendo planejado
MIDP e TIDP não planejam apenas “arquivos BIM”. O objeto do planejamento são information containers: unidades de informação identificáveis que podem assumir diferentes formas conforme o processo e a disciplina. Um container pode ser um modelo, desenho, relatório, especificação, planilha, base estruturada, matriz, memorial, conjunto de dados ou outro pacote de informação definido pelo processo.
TIDP — plano de entrega do task team
O TIDP é elaborado no nível do task team. Ele deve refletir como aquela equipe pretende produzir seus containers considerando requisitos, capacidade, dependências e datas necessárias.
Um TIDP tecnicamente útil não deve ser apenas uma lista de documentos. Ele precisa permitir responder, para cada entrega, pelo menos às perguntas: o que será produzido, por quem, para qual finalidade, em qual marco, de que informação depende, qual nível de informação é necessário e quando estará pronto para seguir ao próximo estado do processo.
| Campo de planejamento | Função no TIDP | Exemplo de controle |
| identificador do container | eliminar ambiguidade | código conforme convenção do projeto |
| descrição | explicar o conteúdo esperado | modelo de distribuição elétrica do pavimento |
| task team | identificar a equipe produtora | elétrica |
| responsável | estabelecer ownership da entrega | responsável de informação da disciplina |
| finalidade | explicar para que será usado | coordenação, orçamento, aprovação |
| marco/data | conectar a uma necessidade real | gate de projeto executivo |
| dependências | registrar predecessores de informação | arquitetura liberada, cargas confirmadas |
| LOIN/requisito | definir suficiência | propriedades e geometria requeridas |
| formato | definir intercâmbio | nativo, IFC, PDF, XLSX, IDS |
| revisão/autorização | prever fluxo interno | check, review, authorize |
| status | acompanhar progresso | planejado, em produção, revisado, entregue |
A granularidade precisa ser equilibrada. Um TIDP com linhas genéricas como “modelo MEP” não ajuda a planejar interfaces. No extremo oposto, decompor cada folha ou pequeno objeto em uma linha independente pode produzir um sistema impossível de manter. A unidade correta é aquela que permite governar responsabilidade, prazo, dependência e aceite.
MIDP — consolidação e coordenação das entregas
O MIDP integra os TIDPs sob a coordenação da lead appointed party. Sua função não é simplesmente copiar as linhas de todas as equipes para uma planilha central. O trabalho principal está na reconciliação.
Duas equipes podem apresentar TIDPs individualmente coerentes e, mesmo assim, formar um plano mestre impossível. Estrutura pode programar uma liberação depois da data em que instalações precisam das reservas; arquitetura pode planejar congelamento de layout depois do início da compatibilização; procurement pode exigir especificações antes de a disciplina concluir sua seleção técnica.
| Situação encontrada na consolidação | Risco | Tratamento no MIDP |
| duas equipes planejam o mesmo container | conflito de autoria e versões | definir owner único |
| requisito sem container correspondente | lacuna de entrega | atribuir responsabilidade e data |
| dependência entregue depois do sucessor | plano inviável | reprogramar ou alterar estratégia |
| datas incompatíveis com gate | atraso de decisão | antecipar ciclo de produção/revisão |
| excesso de entregas no mesmo marco | pico de capacidade e revisão | balancear ondas/data drops |
| formato incompatível com uso | retrabalho de conversão | corrigir requisito de intercâmbio |
| container sem critério de aceite | entrega sem definição de “pronto” | vincular LOIN/checks/aceite |
O MIDP se torna, portanto, uma visão integrada de demanda de informação, capacidade de produção e sequência de dependências.
MIDP não é a soma mecânica dos TIDPs. A consolidação precisa testar cobertura, capacidade, dependências e compatibilidade das datas antes de formar a baseline de informação do projeto.
MIDP e TIDP são planos vivos, mas não podem ser voláteis
Mudanças autorizadas de escopo, contratação, design, marcos ou estratégia podem exigir revisão dos planos. Isso não significa reescrever datas informalmente sempre que um atraso ocorre. A revisão precisa ser controlada, versionada e justificável.
Uma boa prática é diferenciar baseline, forecast e actual. A baseline registra o compromisso aprovado; o forecast mostra a previsão atual; o actual registra quando o container realmente alcançou o estado ou marco definido. Sem essa separação, o projeto perde a capacidade de medir atraso porque o plano é continuamente ajustado para coincidir com o realizado.
EIR, BEP, TIDP e MIDP: cadeia de rastreabilidade da informação
Esses artefatos precisam ser entendidos como partes diferentes de um mesmo sistema.
| Artefato | Pergunta principal | Saída esperada |
| PIR/EIR | que informação é necessária e quando? | requisitos de projeto e de troca |
| BEP | como a equipe responderá aos requisitos? | método, processos, papéis e padrões |
| TIDP | o que cada task team produzirá e quando? | plano de containers por equipe |
| MIDP | como todas as entregas se encaixam? | plano mestre coordenado |
| CDE | o que foi efetivamente produzido e em qual estado? | registro controlado da informação |
| aceite | a entrega atende ao requisito e pode ser usada? | evidência de conformidade/aceitação |
Requisito precisa terminar em entrega verificável
Um requisito genérico como “fornecer modelo de ativos” não é suficiente para controle. É necessário saber quais containers materializam esse requisito, quais objetos ou atributos precisam existir, em que marco, em qual formato e como será verificado.
A rastreabilidade madura permite navegar nos dois sentidos: do EIR até o container que o atende e do container de volta ao requisito que justificou sua produção. Isso reduz entregas sem finalidade e ajuda a identificar requisitos que ainda não possuem responsável.
Requisito sem container identificável não é controlável. EIR, TIDP, MIDP, CDE e aceite precisam formar uma cadeia rastreável entre necessidade, produção, prazo e evidência.
BEP define a forma de trabalhar; TIDP e MIDP materializam compromissos
O BEP normalmente descreve abordagem de produção, coordenação, software, CDE, nomenclatura, estrutura de equipe, processos de QA e intercâmbio. TIDP e MIDP transformam essa metodologia em uma agenda concreta de entregas.
O BEP pode, por exemplo, determinar que modelos sejam verificados internamente antes de compartilhamento. O TIDP deve então prever tempo suficiente entre conclusão da autoria e o marco de compartilhamento para que o check e a correção ocorram. Se o plano ignora esse intervalo, a metodologia descrita no BEP torna-se inexequível.
TIDP precisa refletir capacidade real do task team
Planejamento de informação não pode ser imposto apenas de cima para baixo. O task team conhece sua sequência de produção, especialidades, dependências e limitações. A data acordada deve resultar da combinação entre a necessidade do projeto e a capacidade real de produzir informação conforme o nível de qualidade requerido.
| Pergunta de capacidade | Por que importa |
| quantos containers precisam ser produzidos no período? | dimensiona carga |
| quais especialistas são recursos restritivos? | revela gargalos |
| quanto tempo de QA existe entre produção e entrega? | evita datas artificiais |
| quais inputs externos ainda não existem? | identifica dependências |
| quantas revisões estão previstas? | dimensiona ciclo de maturação |
| há automação ou checking disponível? | altera esforço e previsibilidade |
Um TIDP inviável produz um MIDP inviável. A consolidação não corrige capacidade insuficiente apenas reorganizando datas em uma planilha.
MIDP integrado ao cronograma, gates e Project Controls
MIDP não substitui o cronograma do empreendimento. O cronograma controla uma rede muito mais ampla de atividades de projeto, contratação, suprimentos, construção, testes e entrega. O MIDP controla a dimensão informacional necessária para que essas atividades possam ocorrer.
A integração entre ambos é essencial porque informação é predecessora de decisão.
Datas de upload não são o verdadeiro marco
Uma entrega só é pontual quando chega antes da necessidade que pretende suportar e possui condição de uso. Se uma especificação é publicada na data planejada, mas depois da emissão da requisição de compra, sua pontualidade administrativa não evita o impacto no projeto.
| Evento do projeto | Informação que pode ser predecessora |
| aprovação de conceito | estudos, alternativas, modelos e memórias |
| congelamento de layout | arquitetura coordenada e requisitos de áreas |
| início de compatibilização | modelos disciplinares em maturidade mínima |
| cotação de equipamento | datasheet, especificação e quantitativos |
| compra | documentos aprovados e critérios de seleção |
| fabricação | desenhos e interfaces liberadas |
| mobilização de obra | projeto executivo liberado |
| execução de trecho | modelo/desenho aprovado para construção |
| comissionamento | listas, requisitos funcionais e documentação |
| handover | as-built, dados de ativos, certificados e manuais |
Essa lógica aproxima MIDP do Project Controls. Atraso de informação deve ser tratado como possível causa de atraso de decisão, procurement ou execução, e não apenas como pendência documental.
Entrega de informação atrasada pode virar atraso de projeto. O marco do MIDP deve ser definido pela decisão, compra ou atividade que depende da informação — não pela conveniência administrativa do upload.
Data drops devem ser orientados por decisão
Agrupar entregas em data drops pode facilitar coordenação e governança, mas o marco precisa existir porque há uma necessidade de decisão ou integração, não porque “todo mês há um upload”.
Para cada data drop, é útil declarar finalidade, conjunto esperado de containers, maturidade, critérios de verificação, responsáveis pela revisão e janela de correção. Isso torna o marco controlável e reduz grandes lotes que chegam sem condição de análise.
Dependências devem aparecer como rede, não somente como observação
Dependência relevante não deveria ficar escondida em uma célula de comentário. O planejamento precisa permitir visualizar predecessor e sucessor de informação.
Exemplos: um modelo estrutural depende de cargas consolidadas; shafts dependem de requisitos de instalações; quantitativos dependem de classificação e maturidade; uma especificação de compra depende da conclusão de requisitos funcionais; um AIM depende de informações de procurement, instalação e comissionamento.
A maturidade aumenta quando essas relações podem ser vinculadas ao cronograma do projeto ou a ferramentas de planejamento em vez de serem geridas apenas por percepção da equipe.
Baseline, forecast e actual permitem medir desempenho
O controle deve preservar o compromisso original e registrar o comportamento real.
| Campo | Significado |
| baseline date | data aprovada do compromisso |
| forecast date | melhor previsão atual |
| actual date | data efetiva de entrega/estado |
| variance | diferença entre baseline e previsão/realizado |
| reason code | causa categorizada do desvio |
| recovery action | ação para evitar impacto subsequente |
Com essa estrutura, MIDP deixa de ser apenas lista de datas e se aproxima de um instrumento de controle de produção de informação.
Qualidade da entrega: LOIN, CDE, IDS, IFC e critérios de aceite
Planejar quando um container será entregue não é suficiente. É necessário definir o que significa estar pronto.
LOIN estabelece suficiência da informação
O Level of Information Need ajuda a especificar a quantidade e granularidade adequadas de geometria, informação alfanumérica e documentação para uma finalidade. O mesmo sistema pode exigir níveis diferentes de informação em estudo, projeto, contratação, execução e handover.
O TIDP pode vincular cada container ao LOIN ou ao conjunto de requisitos aplicável. Isso reduz duas falhas recorrentes: sobreprodução de informação muito antes de ela ser necessária e entrega de um modelo formalmente existente, mas insuficiente para a decisão.
Critério de “pronto” deve incluir QA e autorização
A data do container não pode representar apenas o momento em que o modelador encerra sua tarefa. Deve existir clareza sobre os estados intermediários.
| Etapa | Pergunta de controle |
| produção | o conteúdo necessário foi desenvolvido? |
| check | a equipe verificou suas próprias regras? |
| review | interfaces e requisitos foram revisados? |
| correção | não conformidades críticas foram tratadas? |
| authorization | alguém com autoridade liberou a troca? |
| sharing/publishing | o container entrou no estado correto no CDE? |
| acceptance | o destinatário confirmou que atende ao requisito? |
Projetos que não diferenciam essas etapas tendem a registrar como “entregue” informação ainda em correção.
IDS e model checking podem automatizar parte da verificação
Quando requisitos alfanuméricos ou de classificação podem ser formalizados em IDS, parte do checking pode ser automatizada sobre entregas IFC. Isso não elimina revisão técnica, mas reduz verificações manuais repetitivas.
O encadeamento é importante: o EIR define a necessidade; LOIN e IDS tornam parte dela verificável; o TIDP define quando o container será produzido; o CDE registra sua entrega; o checking gera evidência objetiva; o processo de aceite decide se a informação está apta para uso.
O CDE é a principal evidência do realizado
MIDP e TIDP representam o planejamento. O CDE deve registrar containers, versões, estados, revisões, responsáveis, datas e autorizações reais.
Uma arquitetura madura pode comparar automaticamente o plano com o CDE por meio de identificadores e metadados consistentes.
| Indicador | Interpretação |
| entregas no prazo | aderência ao plano |
| entregas previstas sem container | lacunas ou atraso |
| containers sem linha no MIDP | produção não planejada |
| taxa de rejeição | qualidade da entrega/requisito |
| tempo de correção | capacidade de resposta |
| reincidência de NC | eficácia de aprendizado |
| duração check→authorize | gargalo de governança |
| forecast variance | risco futuro antes do atraso real |
Esse fechamento entre plano e realizado cria a base para auditoria de informação.
MIDP/TIDP representam o plano; o CDE registra o realizado. Identificadores e metadados consistentes permitem comparar previsão, estado, versão, data e aceite de cada container.
Governança, responsabilidades e gestão de mudanças do plano
O plano precisa ter ownership claro. Em projetos complexos, manter um MIDP confiável exige disciplina semelhante à de outros instrumentos de planejamento.
Task team responde por seu TIDP; integração exige coordenação superior
Cada task team precisa assumir responsabilidade sobre suas entregas e previsões. A lead appointed party precisa coordenar o conjunto, testar consistência e tratar conflitos entre equipes.
Isso não significa centralizar toda atualização em um BIM Manager. O modelo mais sustentável distribui ownership da informação e mantém uma função de coordenação que consolida, desafia e controla o plano mestre.
Mudanças de data precisam de causa e impacto
Alterar uma data porque “a equipe atrasou” apenas oculta o problema. Uma mudança relevante deve identificar a causa e avaliar o efeito sobre sucessores.
Causas recorrentes podem incluir mudança de escopo, atraso de input, decisão pendente, alteração de requisito, capacidade insuficiente, revisão técnica adicional, mudança de fornecedor ou erro de planejamento.
| Tipo de mudança | Tratamento recomendado |
| mudança contratual | atualizar requisito, escopo e plano mediante aprovação |
| input externo atrasado | registrar impacto e reprogramar dependentes |
| erro de estimativa | revisar forecast preservando baseline |
| mudança de design | identificar containers afetados e reemitir sequência |
| nova equipe/fornecedor | atualizar TIDPs e responsabilidades |
| requisito adicional | criar rastreabilidade até novos containers |
| atraso sem aprovação | registrar desvio; não apagar baseline |
MIDP não deve competir com o cronograma mestre
Criar dois sistemas independentes de datas gera reconciliação manual permanente. O ideal é definir qual sistema governa cada camada e como as datas se relacionam.
O cronograma mestre pode controlar milestones e atividades; MIDP controla containers e marcos de informação. A integração pode ocorrer por IDs, códigos de atividade, WBS, localização, pacote de trabalho ou outra chave estável.
Automatizar apenas depois de estabilizar codificação e processo
Dashboards que comparam MIDP com CDE são muito úteis, mas dependem de estrutura consistente. Identificadores, estados, metadados, nomes de task teams e códigos de milestone precisam ser controlados antes da automação.
Automação sobre dados inconsistentes produz indicadores visualmente sofisticados e operacionalmente incorretos.
Como implantar MIDP e TIDP em um projeto BIM
O objetivo da implantação é fazer com que os planos participem da rotina de produção, coordenação e decisão. Se o documento só é atualizado antes de auditorias ou reuniões contratuais, ele perdeu sua função.
Processo recomendado de implantação e controle
- Revisar PIR, EIR, appointments e milestones. Identificar requisitos, obrigações e datas de decisão.
- Mapear task teams e interfaces. Determinar quem produz quais conjuntos de informação.
- Definir convenção de identificadores. Padronizar containers, equipes, pacotes e marcos.
- Definir estrutura mínima do TIDP. Campos, responsabilidades, LOIN, dependências, estados e datas.
- Decompor entregáveis em containers controláveis. Evitar tanto linhas vagas quanto granularidade administrativa excessiva.
- Rastrear containers aos requisitos. Garantir que cada entrega tenha finalidade e cada requisito tenha cobertura.
- Mapear dependências entre equipes. Identificar inputs necessários antes de comprometer datas.
- Planejar produção, QA e autorização. Não confundir fim da autoria com disponibilidade para uso.
- Preparar TIDPs com os task teams. Validar capacidade, sequência e responsáveis reais.
- Consolidar os TIDPs em MIDP. Criar uma visão mestre das entregas.
- Reconciliar conflitos, lacunas e duplicidades. Ajustar dependências e ownership antes da baseline.
- Integrar MIDP aos milestones e cronograma. Vincular informação às decisões e atividades que dependem dela.
- Definir baseline, forecast e actual. Preservar compromisso e permitir medição de variância.
- Configurar controle no CDE. Usar IDs e metadados que permitam comparar plano e realizado.
- Controlar qualidade, atraso e causas. Medir entregas, rejeições, aging, forecast e impacto em sucessores.
- Gerir mudanças e rebaseline somente quando autorizado. Manter histórico e rastreabilidade do compromisso.
Reuniões devem usar o MIDP como instrumento de decisão
O plano ganha valor quando orienta perguntas concretas: qual informação vence nas próximas semanas? quais dependências ainda não foram liberadas? quais task teams possuem maior variance? quais entregas estão em risco de perder o gate? qual decisão precisa ser antecipada para proteger o cronograma?
Isso aproxima o MIDP de práticas de lookahead e controle de restrições. A equipe passa a atuar sobre o risco futuro, em vez de apenas contabilizar documentos atrasados.
Critérios de aceite do próprio plano
Antes de aceitar um MIDP como baseline, é possível verificar sua qualidade.
| Critério | Verificação |
| cobertura | todos os requisitos relevantes possuem entregas? |
| ownership | todo container possui responsável? |
| temporalidade | datas suportam decisões e atividades? |
| dependências | precedências críticas estão identificadas? |
| capacidade | task teams conseguem cumprir os compromissos? |
| QA | revisão e autorização estão contempladas? |
| rastreabilidade | requisito → container → entrega pode ser demonstrado? |
| CDE | codificação e estados permitem controle do realizado? |
| governança | atualização, aprovação e mudança estão definidas? |
O resultado esperado é previsibilidade da informação. Cada task team sabe o que precisa produzir, em que condição e até quando; a coordenação entende como os containers se encadeiam; o CDE registra o realizado; e o projeto consegue identificar risco de atraso de informação antes que ele se transforme em atraso de engenharia, contratação, obra ou operação.
Rebaseline não pode apagar atraso. Baseline, forecast e actual devem permanecer separados para preservar o compromisso original, medir variância e controlar mudanças autorizadas.
Referências técnicas
[1] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 19650-2:2018 — Organization and digitization of information about buildings and civil engineering works, including BIM — Information management using BIM — Part 2: Delivery phase of the assets. Geneva: ISO, 2018. Disponível em: ISO.
[2] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO/DIS 19650-2 — Information management — Part 2: Information management process. Draft International Standard em desenvolvimento em 2026. Disponível em: ISO.
[3] UK BIM FRAMEWORK. Guidance and resources for information management using the ISO 19650 series. Disponível em: UK BIM Framework.
[4] UK BIM FRAMEWORK. Frequently Asked Questions — ISO 19650 information management. Disponível em: UK BIM Framework.
Perguntas frequentes
TIDP é Task Information Delivery Plan, o plano de entregas de informação de um task team. Ele organiza os information containers que a equipe produzirá, seus responsáveis, marcos, dependências e requisitos.
MIDP é Master Information Delivery Plan, o plano mestre que consolida e coordena os TIDPs dos task teams para formar uma visão integrada das entregas de informação do projeto.
O TIDP opera no nível do task team. O MIDP coordena o conjunto dos planos das equipes e resolve dependências, lacunas, duplicidades e conflitos de datas no nível do projeto.
Não. MIDP é o plano das entregas de informação. Ele precisa estar integrado ao cronograma porque documentos, modelos e dados frequentemente são predecessores de decisões, compras e atividades de execução.
O EIR define o que precisa ser trocado; o BEP descreve como a equipe responderá; o TIDP planeja as entregas de cada task team; e o MIDP coordena essas entregas em um plano mestre.
O TIDP deve ser preparado no contexto do task team que conhece sua produção, capacidade e dependências, dentro dos requisitos e responsabilidades do appointment.
A consolidação ocorre sob a coordenação da lead appointed party, reconciliando os TIDPs e assegurando que o conjunto atenda aos requisitos e marcos.
Para controle consistente, é recomendável preservar uma baseline aprovada e separar forecast e actual. Isso permite medir variância sem apagar o compromisso original a cada atualização.
MIDP e TIDP representam o plano. O CDE registra os containers efetivamente produzidos, suas versões, estados, datas e autorizações. Comparar os dois permite medir desempenho.
Use o plano nas rotinas de lookahead, coordenação, gestão de restrições, controle de marcos e aceite. Se ele não influencia decisões ou acompanhamento, sua estrutura deve ser simplificada ou integrada aos processos reais.
Materiais técnicos complementares
ISO 19650, requisitos e planejamento da informação
- Gestão da Informação em BIM: ISO 19650
- Requisitos de Informação BIM: OIR, AIR, PIR e EIR
- BEP BIM
- LOIN no BIM
CDE, interoperabilidade e qualidade das entregas
Equipes, coordenação e produção BIM
- BIM Coordinator, BIM Manager e BIM Modeler
- Implantação BIM
- Modelagem BIM em Engenharia
- Projeto BIM em Engenharia
- Modelo Federado BIM
