Eles dizem que querem uma solução
Este artigo faz parte da nossa coleção "From the Trenches". Ele descreve alguns desafios comuns que você pode enfrentar ao agendar projetos. Ele descreve a melhor abordagem quando você tenta determinar quanto tempo as tarefas devem ser e quantas tarefas devem haver para otimizar um agendamento de projeto. Ele discute como diferentes indústrias normalmente exigem diferentes tipos de agendamentos (por exemplo, desenvolvimento de software, EPM (engenharia, compras e construção) e desligamento da fábrica). Ele também discute vários fatores na escolha da resolução do projeto (por exemplo, duração do projeto, recursos envolvidos, gerenciamento ou divisão de recursos, velocidade e esforço necessários na coleta de dados e agendamento de atualização de dados).
Para baixar a versão do Word deste artigo, consulte Eles dizem que querem uma resolução: white paper (Project Server 2010).
Para ver mais artigos, consulte white papers "From the Trenches".
Eles dizem que querem uma solução
Com desculpas aos Beatles pelo título, o tópico de hoje é a resolução do seu projeto.
Há muitos materiais disponíveis sobre como fazer uma agenda, mas uma das lições mais críticas é muito difícil de encontrar: quantas tarefas você deve ter na agenda do projeto e quanto tempo cada tarefa deve ser?
Regularmente, sou confrontado com agendas de projetos que parecem impossivelmente complexas ou com gerentes de projeto que parecem impotentes para identificar problemas em sua agenda porque a agenda está em um nível tão resumido. Eu vi um projeto que tinha mais de cem anos de duração (sim, realmente) que era perfeitamente apropriado em comprimento e no qual havia algumas tarefas que tinham décadas de duração. Também vi agendas de projetos que duraram apenas uma hora ou menos que eram perfeitamente apropriadas e nas quais algumas tarefas duravam apenas um minuto. Já vi projetos com apenas um punhado de tarefas e outros com mais de 100.000 tarefas.
O software que usamos hoje pode lidar com milhares de tarefas e uma ampla gama de durações.
Então, qual é a abordagem certa?
Quanto tempo as tarefas devem ser e quantas devemos ter para otimizar nossa agenda de projetos? Chamarei isso de resolução do projeto.
Traços diferentes para pessoas diferentes
Como o requisito pode ser diferente para diferentes indústrias, diferentes tipos de projetos e situações diferentes, vamos examinar como decidir quantas tarefas colocar em sua agenda e quanto tempo as tarefas devem ser.
Diferentes tipos de projetos naturalmente exigem diferentes tipos de agendamentos. Vamos pensar em três exemplos diferentes:
Desenvolvimento de software. Muitos projetos de software têm características comuns. Embora cada projeto de software seja exclusivo, normalmente há uma fase de design, uma fase de programação, uma fase de garantia de qualidade, uma fase de documento e uma fase de implantação. Projetos de software normalmente são medidos em semanas ou meses, e isso se presta a tarefas que têm um dia a algumas semanas de duração. A alocação de recursos aqui geralmente é atribuída ao nível individual.
Aqueles que adotaram o processo Agile para desenvolver software olham para "sprints" curtos de uma ou duas semanas e dentro desse sprint colocam tarefas de duração breve, mas a duração geral do projeto ainda é medida em semanas. Falaremos mais sobre o desenvolvimento do Agile um pouco mais tarde.
EPC – Engenharia, Compras e Construção. Os projetos EPC são onde a metodologia de Agendamento de Caminho Crítico começou. Nesse tipo de projeto, algo muito grande está sendo desenvolvido. Pode ser um grande projeto de defesa como o projeto do Míssil Polaris que deu aos diagramas PERT seu início, ou poderia ser uma plataforma de petróleo offshore, um novo navio ou uma usina. Nesses tipos de projetos, há uma fase de engenharia em que o projeto concluído é concebido. A fase engenharia normalmente tem algum aspecto que nunca foi projetado antes. A fase de Aquisição analisa a localização, a contratação e o gerenciamento da entrega de suprimentos ou subcontratos para elementos do projeto. Na fase construção, o produto final é construído e, em seguida, comissionado para uso. Normalmente pensamos em agendas de projetos do EPC em muitos meses ou vários anos com durações de atividade que duram em qualquer lugar de algumas semanas a alguns meses. Não é nada incomum ter de 5.000 a 20.000 tarefas em tal projeto. O agendamento de recursos aqui é quase sempre atribuído ao nível de habilidade, em vez do indivíduo, e (apenas para adicionar à diversão) pode haver muitos subprojetos transformados em um programa ou projeto mestre para facilitar o gerenciamento.
Desligamento da fábrica. Quando você faz um agendamento de projeto para um desligamento da fábrica e uma reviravolta para manutenção, você está trabalhando em um dos ambientes de agendamento mais desafiadores possíveis. Um desligamento da planta para fazer a manutenção vem em dois sabores: planejado e de emergência. Vamos deixar o tipo de emergência de lado por um momento; é um mundo para si mesmo. A duração de uma paralisação planejada da fábrica depende fortemente do tipo de planta. Uma unidade de usina nuclear, por exemplo, pode fazer uma paralisação e reviravolta "rápida" da usina em 12 meses. Uma refinaria de petróleo pode durar de 4 a 6 semanas. Mas o tipo de agenda de projeto de fábrica que acho mais interessante é uma fábrica como uma siderúrgica, uma fábrica de papel ou algo semelhante. Há milhares ou dezenas de milhares dessas plantas em todo o mundo, e elas devem passar por manutenção regular todos os anos ou mais.
O custo do desligamento para essas situações geralmente é medido em custo de oportunidade; o custo do produto que não será produzido enquanto a fábrica estiver ociosa e passando por manutenção. Esse custo é medido em horas, e o custo pode ser superior a US $ 150.000 a US $ 250.000 por hora! Portanto, a pressão é de minuto a minuto para fazer o trabalho. Nesse tipo de situação, a paralisação normalmente dura de 5 a 8 dias e o atraso de um único dia é calculado em milhões. Se você só está acostumado a agendas mais longas e tradicionais, você pode pensar que em poucos dias, "quantas tarefas normalmente poderiam haver?" mas não é nada incomum que tal desligamento tenha de 2.000 a 4.000 tarefas, cada uma com duração de 15 minutos a algumas horas. As atribuições de recursos aqui são feitas por habilidade, mas o nivelamento de recursos raramente é feito no pessoal. Com o custo por hora sendo tão intenso, não importa se você colocar mais pessoas no projeto, basta fazê-lo com pressa. O nivelamento de recursos nessa situação geralmente é feito para gargalos altamente restritos. Por exemplo, "só podemos encaixar duas pessoas na sala elétrica, então isso tem que ser gerenciado de forma discreta".
Ok, agora temos três tipos de exemplos, e há muitos mais, mas esses três servirão muito bem aos propósitos da discussão. No tipo um (desenvolvimento de software), obtemos tarefas que normalmente têm um dia ou dois dias a duas semanas de duração. No tipo dois (EPC), obtemos tarefas que têm semanas ou meses de duração. No tipo três (desligamento da planta), obtemos tarefas que são medidas em unidades de 6 minutos (1/10 de uma hora), 10 minutos, 15 minutos (1/4 de hora), até algumas horas de duração. É óbvio que, em alguns casos, tarefas curtas fazem sentido e em outras tarefas longas são mais apropriadas. Seguindo a mesma lógica, às vezes faz sentido ter um grande número de tarefas e às vezes simplesmente não faz.
Fatores na escolha da resolução do projeto
Com essas três distinções, é fácil ver que a tarefa de projeto EPC de dois meses pareceria ridícula em um agendamento de desligamento de seis dias e que uma tarefa de 15 minutos estaria fora do lugar no projeto EPC ou Software. Mas além de se referir a este artigo e dizer: "Vandersluis diz que é um projeto de software, então as tarefas só podem ter de 1 a 10 dias de duração", (e por favor, não faça isso) quais características do projeto nos dizem qual nível de resolução escolher? Vamos dar uma olhada em algumas óbvias:
Quanto tempo é o projeto?
Vamos começar com o mais óbvio. Se espera-se que seu projeto tenha alguns dias de duração, como em nosso exemplo de desligamento, ter tarefas com vários dias de duração não faz sentido algum. Começar com uma abordagem de cima para baixo geralmente é produtivo quando pensamos em subdividenciar o escopo. Use o pensamento de estrutura de detalhamento de trabalho. Comece com os principais componentes. Pense em ter nada menos que 4 e não mais de 20 itens.
É uma regra? Não, claro que não.
É senso comum. Menos de 4 faz você se perguntar por que você dividiu o trabalho em tudo e mais de 20 é muito difícil de manter em mente ao mesmo tempo. Pessoalmente, eu vou com não mais do que 8 itens por elemento WBS e isso é por causa de algum artigo que li anos atrás que sugeria que um octógono era a forma mais complexa e simples que a mente poderia reconhecer imediatamente.
Pense nisso por um momento. Você pode identificar um círculo, um triângulo, um quadrado, um pentágono, um hexágono que tem seis lados, um heptagono que tem sete lados (ok, esse é difícil de visualizar) e um octógono.
Você pode identificar uma forma de 9 lados sem contar? Não posso. É chamado de "nonagon" para vocês, fãs de curiosidades.
Então, pessoalmente, eu me esforço para o limite de 8 itens, mas minha regra de ouro é 4-20.
Para cada elemento que você analisou, pense em como você deve dividir o trabalho. Novamente, pense na regra 4-20. Mas saber quando parar é o segredo. Os gerentes de projeto mais recentes sub-dividirão e sub-dividirão e sub-dividirão até que cada etapa abaixo do corredor seja uma tarefa gerenciada. Algumas boas perguntas de divisor de águas que você pode fazer a si mesmo sobre a duração de uma tarefa podem ser:
Que ação eu tomaria se essa tarefa estivesse atrasada? Se a resposta for "nada", então é uma boa indicação de que a tarefa que você está pensando é muito pequena para valer a pena gerenciar. Se esse for o caso, você está olhando com muitos detalhes. Faça backup de um nível, dê um passo atrás e veja se você terminou.
A coleta dos dados sobre a atualização dessa tarefa levará mais tempo do que a tarefa em si? Nem sempre pensamos em que tipo de esforço será necessário para gerenciar uma tarefa agendada, mas vale a pena pensar, mesmo que por um momento. Se for preciso mais esforço para gerenciar a tarefa do que será necessário para ser concluída, isso é uma boa indicação de que a tarefa está sendo definida em um nível muito bom de detalhes.
Quanto tempo é essa tarefa? Quando estamos dividindo o trabalho, às vezes perdemos de vista o quão minúscula uma tarefa se torna. As grandes fases no nível superior foram talvez semanas de duração, mas à medida que descemos alguns níveis de granularidade, podemos facilmente cair na armadilha de definir uma tarefa a ser gerenciada que tem apenas alguns minutos de duração. Quando chegarmos a pequenas tarefas, temos que perguntar qual seria o benefício de gerenciá-las.
Vamos aplicar uma verificação de realidade ao que acabei de falar. Em um projeto EPC de dois anos, se uma tarefa de uma semana estiver um dia atrasada, quase certamente não vale a pena tomar medidas. Em um projeto de software de seis meses, uma tarefa de uma semana com um dia de atraso provavelmente não vale a pena tomar medidas. Em um projeto de desligamento de seis dias, uma tarefa de uma semana que está um dia atrasada é uma emergência maciça. Em outras palavras, uma tarefa de uma semana no projeto EPC pode ser um nível de detalhe muito fino; no projeto de software, provavelmente está quase certo; e no projeto Shutdown, ele quase certamente precisa ser dividido em mais detalhes.
Quantos recursos estão envolvidos?
Sei que estamos apenas trabalhando no escopo, mas quando olhamos para que tipo de resolução precisamos, vale a pena pensar em quantas pessoas trabalharão em uma tarefa. Em um grande projeto EPC, por exemplo, podemos ter dezenas de trabalhadores de uma habilidade envolvida em uma fase de trabalho. Mas quando acabamos com muitas habilidades diferentes na mesma tarefa, gerenciar essa tarefa torna-se muito desafiador, se não impossível. Portanto, nessa situação, tarefas que exigem muitas habilidades diferentes provavelmente precisam ser divididas.
Em um projeto de software, tendemos a pensar em quase todos os indivíduos como um recurso altamente técnico com recursos exclusivos. Além disso, em projetos de software é comum ter muitas tarefas que são reatribuíveis em um departamento, mas apenas uma tarefa atribuída a uma pessoa. Portanto, quando temos tarefas alocadas para um nível de uma pessoa de um determinado grupo de recursos ou departamento (por exemplo, programação de interface) estamos próximos o suficiente para dizer que não precisamos de mais detalhes.
Como os recursos são gerenciados ou subdivididos?
Como os recursos são gerenciados é um grande determinante em como sub-dividir suas tarefas. Em grandes projetos EPC, por exemplo, os projetos geralmente são cortados em subprojetos que são parcelados para grandes subcontratados. Nesta situação, precisamos fazer algumas coisas:
Defina o trabalho de uma maneira que permita que um gerente de projeto supervisione o subcontratado com confiança de que o progresso que está sendo feito é um grande fator.
Defina as tarefas de uma forma que a equipe de gerenciamento de projetos e engenharia do subcontratado entenderá o que elas significam sem ambiguidade.
Verifique se o nível de resolução que você adotou como padrão é compreendido e acordado pelo subcontratado.
Quando olhamos para projetos de colarinho branco, como software, pesquisa biológica ou engenharia, é mais provável que encontremos uma estrutura de Gerenciamento de Matriz onde os gerentes de projeto não possuem nenhum dos recursos e devemos trabalhar entre os gerentes de departamento que alocam esses recursos em muitos projetos diferentes. Nesse caso, as principais perguntas seriam:
Quantos projetos é provável que um recurso funcione em um único dia?
Quanto tempo um funcionário leva para mudar de um projeto para outro?
O trabalho é definido de modo que os funcionários e os gerentes do departamento de recursos entendam como alocar a habilidade certa para ele?
Quando olhamos para um projeto de Desligamento ou Construção, tendemos a trabalhar entre equipes que são criadas com propósito. Nessas situações, um Líder da Equipe de Recursos pode estar gerenciando a Equipe Elétrica (mesmo que essa equipe inclua carpinteiros e pipe-fitters), uma Equipe de Encanamento ou uma Equipe de Reforma da Unidade de Caldeiras. O trabalho tem que ser organizado de tal forma que a tripulação possa ser mantida ocupada durante todo o turno e que eles não cheguem em cima de outra tripulação já trabalhando em algo nessa área. Dada a intensa pressão de concluir um projeto de Desligamento, o trabalho geralmente é organizado pelo trabalho primeiro, agendado e, em seguida, reagrupado e subdividido por um Líder da Equipe de Recursos para que cada líder de equipe possa andar por aí apenas com suas tarefas em um documento e com todo o projeto em contexto em outro. Portanto, as tarefas precisam ser definidas de forma compreensível pelo funcionário e pelo Líder da Equipe de Recursos. As tarefas aqui provavelmente são definidas até a hora ou com ainda mais granularidade para o décimo ou quarto de hora.
Com que rapidez você pode coletar dados e quanto esforço isso leva?
Parece uma pergunta boba quando você está acostumado a ver seus dados do projeto bem alinhados no final da semana para serem revisados, mas quando você está tentando determinar o nível de resolução do seu projeto, essa pode ser uma pergunta fundamental. Por exemplo, quando você está trabalhando em vários subcontratados, é provável que você receba algum tipo de atualização semanal ou mensal. Na verdade, criar a cláusula de atualização de gerenciamento de projeto em seu contrato é essencial. Nessa situação, você precisa integrar os dados dessas diferentes empresas à sua própria, validar se os dados de progresso fazem sentido e, em seguida, fazer sua própria análise e relatório. Em um modo EPC, isso provavelmente é uma ocorrência mensal.
Em um projeto de desligamento, você precisará atualizar seu projeto a cada turno, atualizá-lo rapidamente e obter as atualizações para os Líderes da Equipe de Recursos no meio do próximo turno. Nessa situação, o pessoal do projeto lota toda a fábrica durante todo o turno, coletando dados o mais próximo possível em tempo real e fazendo com que os Líderes da Equipe de Recursos e Foremen usem planilhas 'take-down' para 'derrubar' o progresso de suas atribuições. Em um projeto de software ou pesquisa, você provavelmente está trabalhando em uma agenda semanal ou algo assim com indivíduos relatando seu próprio progresso e passando por aprovações ao longo de um ou dois dias.
Esse é um ponto importante a ser considerado quando você está analisando quantas tarefas ter em seu projeto, pois há um custo para coletar os dados.
Portanto, pensar na rapidez com que você pode coletar, aprovar, integrar, analisar e relatar os dados regularmente é fundamental, assim como a consideração do custo de coleta dos dados e o retorno sobre o investimento desses dados que estão sendo coletados.
Com que frequência atualizaremos?
Aqui estão duas chaves para determinar quantos dados você pode coletar e incluir:
Pense em como você coletará seus dados.
Pense na frequência com que você pode atualizar razoavelmente seu projeto e fornecer gerenciamento com as ferramentas de tomada de decisão necessárias para orientar o projeto e os recursos na direção certa.
Vi alguns gerentes de projeto insistirem que querem mudar para o gerenciamento de projetos e a coleção de projetos em tempo real e, embora isso possa ser possível em teoria, é terrivelmente difícil de perceber na prática.
Quando olhamos para os dados de gerenciamento de projetos, fazemos algumas suposições. Supomos que:
Os dados estão todos lá. Não esperamos examinar algumas tarefas que são atualizadas e outras que não são.
Todos os dados foram atualizados em um momento semelhante. Não esperamos que metade das tarefas tenham sido atualizadas há alguns minutos, mas a outra metade não foi atualizada por duas semanas.
Todos os dados tiveram algum nível de aprovação. Esperamos que o gerente de projeto fique por trás dos dados que estão sendo apresentados e que ele ou ela seja capaz de dizer "Esta é uma representação justa e precisa do projeto".
Os dados pertencem juntos. Não esperamos que o risco seja desfocado com custos e com recursos, a menos que tenhamos projetado especificamente nossos relatórios e análises dessa forma.
Muitas vezes pergunto aos executivos que estão entusiasmados com o conceito de gerenciamento de projetos em tempo real o que eles farão se pudéssemos superar os pontos que acabei de levantar acima. "Você está preparado para tomar decisões de gerenciamento durante toda a semana?" Eu vou perguntar. A resposta deve depender do nível de resolução. Em um projeto de desligamento, é melhor que a resposta seja "Sim". Em um projeto de software, a resposta provavelmente é "Não, faremos isso semanalmente". E em um projeto EPC, a resposta seria : "Mensal".
Em algum momento, a lei de diminuição de retornos começa a dizer: "Entregar relatórios de projeto mais rápido não nos dará nenhum aumento na eficiência."
Revisando seu trabalho
Você já teve algum alimento para pensar, usou o Método de Divisão de Trabalho para sub-dividir seus dados e observou alguns dos sinais de aviso de que os dados estão muito bem definidos. Agora é hora de inclinar a agenda contra a parede, dar um passo atrás e olhar para o projeto com alguma perspectiva. Surpreendentemente, muitos gerentes de projeto nunca fazem isso. Eles ficam tão envolvidos em obter os últimos detalhes definidos e estão tão ocupados sub-divisão tarefas de novo e de novo que eles se empurram até o prazo de transmissão e nunca olham para cima para ver se o que eles fizeram será um pesadelo para gerenciar.
Em alguns casos, os executivos têm certeza de todo esse treinamento de MBA que "mais detalhes são melhores" e estão pressionando por essas tarefas de 5 ou 15 minutos em projetos de seis meses.
Alterar o projeto antes de começar é sempre mais fácil do que em qualquer momento posterior, portanto, crie tempo em sua atividade de compilação de agendamento para reformular a agenda, se necessário.
É demais?
Às vezes, os gerentes de projeto analisam o escopo do que criaram e percebem que estão em um nível muito bom de detalhes. Se esse for o caso, a correção será óbvia. Pode ser muito trabalho, mas você vai agradecer a si mesmo mais tarde para tornar a agenda mais simples, subindo um nível.
Às vezes, a imagem não é tão fácil. Em alguns casos, é apenas quando toda a agenda é montada que o gerente do projeto pode ver o quão complexa ela é. Projetos complexos são, por sua própria natureza, mais arriscados e de risco na economia atual é um fator de seleção fundamental para projetos. Algumas perguntas que valem a pena considerar antes de um projeto tão complexo começar podem ser:
Podemos fazer isso em pedaços? Alguns projetos arriscados podem ser divididos em partes menores do tamanho da mordida e, à medida que projetos menores, seu risco diminui. No entanto, se você estiver usando essa estratégia, cada projeto discreto deverá ter seu próprio valor quando for concluído.
Devemos repensar o escopo? Às vezes, as ações mais simples são voltar para os designers da obra em primeiro lugar, explicar a complexidade que parece aparente na agenda e ver se o trabalho pode ser reestilizado. Isso muitas vezes leva a um pensamento inovador que nunca teria tido a chance de ocorrer.
Devemos fazer isso?
Alguns projetos nunca foram feitos para ser, e a hora mais barata para cancelá-los é um dia antes de começar. Se o risco do projeto só agora for aparente, é melhor perceber isso agora do que mais tarde. Quando você tece as conclusões de fazer sua agenda de volta ao processo de PPM (Gerenciamento de Portfólio de Projetos), você pode descobrir que o risco do projeto mais complexo tem a pontuação de trabalho muito pior em uma escala de retorno sobre o investimento.
Um ágil... não, um projeto Agile
Eu prometi dizer algumas coisas sobre o gerenciamento de projetos agile e se você é um fã do Agile e você leu até agora, agradeço sua paciência. Gerenciar projetos de software por meio do método Agile é uma espécie de filosofia, mas é uma filosofia cada vez mais popular com aqueles que foram queimados em projetos maciços de desenvolvimento de software que falharam.
Em um mundo de desenvolvimento de software agile, tentamos dividir nosso projeto em "sprints" de uma a três semanas do tamanho da mordida e a meta para cada miniprojeto é acabar com código utilizável. Neste caso, estamos trabalhando dentro de algumas restrições bastante conhecidas para que nosso nível de resolução seja praticamente escolhido para nós.
Temos uma janela de uma a três semanas, os recursos estão disponíveis para nós e vamos atribuir trabalho a cada recurso. O número de tarefas possíveis que podemos definir nessa estrutura é finito e isso se presta a manter um nível apropriado de resolução. Sim, você pode ter problemas no Agile definindo tarefas que são muito curtas. "Definir Campo1: 10 minutos, Definir Campo2: 10 minutos, Definir Campo3: 10 minutos" etc. mas é muito menos comum.
Agile foi projetado para um ambiente de desenvolvimento corporativo onde estamos criando software para uso interno, e seu uso geralmente é estendido ao desenvolvimento de software comercial. (Usamos o método aqui no HMS para nosso próprio desenvolvimento do TimeControl.) O método Agile resulta em um departamento de desenvolvimento mais manobrável e ágil, mas não será aplicável a todos os setores ou mesmo a todas as empresas de software. Se você estiver fazendo o gerenciamento de projetos em um ambiente de software, minha recomendação é ler no Agile, aprender com ele e, em seguida, adotar esses elementos (todos, alguns ou nenhum) que o tornarão mais eficaz.
Encerrando
Como acontece com a maioria dos aspectos do gerenciamento de projetos, não há uma resposta definida para perguntas que a princípio parecem ser tão óbvias. Quantas tarefas você tem em seu projeto e quanto tempo cada uma dessas tarefas deve ser é algo que você precisa procurar por si mesmo para decidir ... mas decida que você deve.
Escolher o nível de resolução do projeto é uma responsabilidade de gerenciamento de projeto que pode ser um fator de sucesso fundamental no gerenciamento da agenda do projeto.
Sobre o autor
Chris Vandersluis é presidente e fundador da Montreal, hms software com sede no Canadá, um parceiro certificado pela Microsoft. Ele é formado em economia pela Universidade McGill e tem mais de 30 anos de experiência na automação de sistemas de controle de projetos. Ele é membro de longa data do PMI (Project Management Institute) e ajudou a fundar os capítulos montreal, Toronto e Quebec do Grupo de Usuários do Projeto Microsoft (MPUG). As publicações para as quais Chris escreveu incluem Fortune, Heavy Construction News, Computing Canada magazine, e PMNetwork do PMI, e ele é um colunista regular do Project Times. Ele ensina Gerenciamento Avançado de Projetos na Universidade McGill e frequentemente fala em funções de associação de gerenciamento de projetos em América do Norte e em todo o mundo. O HMS Software é o editor do sistema de timekeeping orientado ao projeto TimeControl e é um Parceiro de Solução de Projeto da Microsoft desde 1995.
Chris Vandersluis pode ser contatado por email em: chris.vandersluis@hms.ca
Se você quiser ler mais artigos relacionados ao EPM por Chris Vandersluis, consulte o site de Diretrizes do EPM do HMS (https://www.epmguidance.com/?page_id=39).