Regras Para Agendamentos De Atividades Em Projetos

Regras para agendamento de
atividades em projetos
Regras gerais de acordo com o
PMI e DoD

Por Nader Khorrami Rad, PMP
Tradução para o português: Wladmir Araujo

Regras para agendamento de atividades em projetos

Regras gerais de acordo com o PMI e DoD

wladmir_araujo@hotmail.com – 31 9157-1777
1ª edição

Por Nader Khorrami Rad, PMP
Tradução para o português: Wladmir Araujo

http://en.khorramirad.info http://br.linkedin.com/in/wladmiraraujo

Regras para Agendamento

Copyright © 2012 Nader Khorrami Rad

Todos os direitos reservados. Este material pode All rights reserved. This material may be freely
ser livremente copiado e distribuído, em parte ou copied and distributed, in part or as a whole,
como um todo, sujeito à inclusão do nome do subject to inclusion of the Author’s name and web
autor e endereço web (www.khorramirad.info). address ( www.khorramirad.info ).
Embora todas as tentativas foram feitas para While all attempts have been made to verify

verificar as informações prestadas nesta information provided in this publication, the
publicação, o autor não assume qualquer Author assumes no responsibility for errors or
responsabilidade por erros ou interpretação contrary interpretation of the subject matter
contrária do assunto aqui tratado. herein.
O autor tentou ser o mais objetivo possível, mas The author has tried to be as objective as possible
pode ter sido influenciado por suas experiências but might have been influenced by his personal
pessoais e práticas preferidas. experiences and preferred practices.

Tradução do material fornecido do inglês para o Translated of material from english to brazillian
português brasileiro realizada por Wladmir Araujo portuguese by Wladmir Araujo


2 http://br.linkedin.com/in/wladmiraraujo en.khorramirad.info

Sobre este e-book

Este mini e-book é gratuito e você pode sempre procurar por edições mais recentes e fazer
downloads em en.khorramirad.info, http://br.linkedin.com/in/wladmiraraujo ou ainda enviando
um e-mail para wladmir_araujo@hotmail.com. Eu ficaria feliz em ter o seu feedback; por favor
contacte-me através info@khorramirad.com ou solicite uma conexão LinkedIn, via
http://ir.linkedin.com/in/naderkhorramirad. Se você achar este e-book útil, por favor, introduza-o e
compartilhe-o em seus sites, blogs e redes sociais. Links rápidos de compartilhamento para o

LinkedIn, Tweeter, Facebook e Google Plus estão embutidos na página de download. Eu ficaria
feliz em receber suas doações através do link de doação PayPal que também está presente na
página de download. Espero que você aproveite este e-book.

Nader Khorrami Rad, PMP
Feb 2012



Sobre o autor

Tenho trabalhado com planejamento e controle de projetos em campo, desde 1997. Sou bacharel
em Engenharia Civil e Filosofia da Ciência (eu sei que você me perguntaria sobre isso se
estivéssemos falando cara a cara, eu adoro filosofia analítica e é por isso que eu escolhi este curso,
mas não tem nada diretamente a ver com a minha trabalho). Sou Project Management
Professional (PMP), Certified ScrumMaster (CSM) e Professional ScrumMaster I (PSM I) . Eu tenho
experiência com diferentes tipos de construção e projetos de plantas . Eu não sou um

desenvolvedor de software na ativa, mas eu gastei muito tempo aprendendo o framework Scrum,
porque eu acredito que é possível ter uma síntese do método tradicional de gerenciamento de
projetos e estruturas ágeis para outros projetos de desenvolvimento de software. Eu sou autor de
35 livros que estão todos escritos em persa, e este é meu primeiro trabalho em Inglês. Você pode
encontrar a lista de livros que eu criei no meu perfil do LinkedIn, se quiser.



Introdução
O público que eu tinha em mente quando eu estava escrevendo este livro foi principalmente do
planejamento e controle do projeto, engenheiros, líderes e gestores. Esta informação também
seria útil para outros membros da equipe de gestão do projeto. Aplicando estas regras vocês
podem até aumentar o tempo e esforço do seu planejamento inicial, mas confiem em mim, terão
este tempo de volta no monitoramento e controle.

Escopo deste e-book
Estas regras são sobre os planos detalhados. Se você estiver usando planejamento em ondas
sucessivas ou planejando por etapas que você pode precisar interpretá-los antes de aplicar. Estas
são todas as regras, resumidamente, são especialmente úteis para o pessoal de planejamento;
existem algumas outras regras e recomendações que você deve aplicar ao seu trabalho, mas eles
não serão abordados aqui. Por exemplo, vamos discutir quanto a duração máxima das atividades,
mas não vamos falar de outras coisas, tais como preenchimento de duração e melhores práticas
para estimar a duração. Finalmente, este livro é todo sobre o planejamento e não cobre nada
sobre controle.



Fontes

As principais fontes utilizadas neste e-book foram:

• Guia das Melhores Práticas de Grenciamento de Projetos (PMBOK Guide), 4ª edição, PMI
• Practical Standard for Scheduling, 2ª edição, PMI
• Guia da Excelência em Planejamento e agendamento (PASEG), Draft 1.1b, National Defense
Industrial Association
• 14-Point Schedule Assessment, USA Defense Contract Management Agency (DCMA), 2011

As duas últimas fontes sãoo referenciadas aqui como sendo documentos do DoD (com alguma
tolerância).

Algumas outras fontes também tiveram menor influência neste e-book.



Regra 1: Documentar a Metodologia de programação ......................................................................... 8
Regra 2: A programação deve ter todo o escopo................................................................................. 10
Regra 3: Tenha cuidado com as tarefas tipo ”level of effort”.............................................................. 12
Regra 4: Regra 4: Atividades devem ter um nome único..................................................................... 13
Regra 5: Nomes de atividades devem ter um verbo............................................................................ 15
Regra 6: Cada atividade deve ter pelo menos uma predessessora e uma sucessora......................... 16
Regra 7: A atividade não deve estar ”solta”........................................................................................ 19
Regra 8: A maioria dos relacionamentos deve ser FS........................................................................... 22
Regra 9: Tente não utilizar relacionamentos SF.................................................................................... 25

Regra 10: Você não deve utilizar folgas grandes................................................................................... 27
Regra 11: Use folgas o mínimo possível................................................................................................ 30
Regra 12: Tenha cuidado com as sobreposições................................................................................... 31
Regra 13: Tenha cuidado com as folgas negativas................................................................................ 35
Regra 14: As atividades não devem ter folgas grandes........................................................................ 37
Regra 15: Não divida as atividades........................................................................................................ 39
Regra 16: Não utilize muitas restrições de data.................................................................................... 42
Regra 17: Crie milestones (marcos) para restrições de data................................................................ 43
Regra 18: Atividades não devem ter durações muito longas............................................................... 44
Regra 19: Utiliza apenas uma unidade de duração.............................................................................. 45


01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19

Regra 1: Documentar a Metodologia de programação
Quando você está se preparando para começar a programação, você provavelmente tem uma
visão de todo o processo. Eu não sei se sua empresa faz você documentá-los ou não, mas quase
todos os padrões e códigos de dizem que você deverá fazê-lo. Este documento pode ser chamado
de Plano de Gestão do Tempo, Planejamento Programação, Metodologia de Planejamento e
Controle de Metodologia, etc. Este documento responde questões como: qual o software que
vamos usar? Como será detalhado o nosso plano? Quais controle para os períodos teremos? Quais
os parâmetros que devemos usar para monitorar o desempenho? Preparar um plano de
gerenciamento do tempo é como planejar o período de planejamento; sempre que quiser assumir
o controle você tem que ter algum tipo de plano, se você quiser ter controle sobre o período de

planejamento, planeje o período! É melhor entregar esse documento para as partes interessadas e
obter a sua aprovação. Isso diminui a chance de mal-entendidos e retrabalhos no futuro. O
diagrama da próxima página mostra uma pequena parte do sistema de gestão de projeto que está
envolvida na programação.

Regras para Agendamento > Regra 1: Documentar a metodologia de agendamento


01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19

Plano de gerenciamento do
tempo

Modelo de programação &
programação

Monitoramento e controle

Execução

Controle integrado de
mudanças

Regras para Agendamento > Regra 1: Documentar a metodologia de agendamento


01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19

Regra 2: A programação deve ter todo o escopo
Sua programação deve refletir todo o escopo do trabalho do projeto, nada menos e nada mais.
Quando estamos falando de escopo do projeto, este não se limita às tarefas necessárias para
produzir resultados, precisamos fazer algum trabalho extra para garantir que teremos o que
estamos esperando (atividades de qualidade), não vamos perder oportunidades, e nós podemos
encarar ameaças (atividades de resposta aos riscos) e assim por diante. Vamos rever todo o
processo de planejamento de escopo: Começamos por identificar objetivos. Em seguida, vá para as
necessidades, os requisitos nos dizem o que queremos para atingir as metas. O próximo passo é
definir o escopo do projeto e a estrutura analítica do projeto, o que nos dará uma visão completa
do produto final e todos os seus elementos. O último passo é converter elementos de projeto para

as obras necessárias para criá-los e adicionar os trabalhos extras (por exemplo, tarefas de resposta
de qualidade e risco) que produzem o nosso escopo do projeto e da estrutura de divisão de
trabalho.
A estrutura de divisão de trabalho é uma estrutura hierárquica de nossos resultados, devemos
então nos perguntar que tipo de tarefas devemos fazer para produzir cada entrega e a resposta é a
nossa lista de atividades. Há duas regras para a criação de WBS:

• Elas devem basear-se em entregas (e não em trabalho);
• Devem cobrir 100% do escopo, nada menos e nada mais.

Regras para Agendamento > Regra 2: A programação deve ter todo o escopo


01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19

Regra 2: A programação deve ter todo o escopo
100% desta regra não se aplica apenas à WBS, é também aplicável a cada elemento do PEP. Se
você chamar um item "Estrutura" ele deve conter todas as estruturas no projeto, nada menos e
nada mais.

O menor nível de WBS que organiza as atividades é normalmente chamado de pacote de trabalho.
Quando você está prestes a quebrar um pacote de trabalho em atividades, você deve ter o cuidado
de adicionar cada trabalho necessário para produzir cada entrega abaixo deste.

Esta regra se aplica a todas as situações. Por exemplo, se as partes interessadas concordam com

algumas mudanças estratégicas e lhe dizem para preparar um novo plano para o restante da obra,
o que deve fazer?

Alguns planejadores preparam um novo plano, que abrange apenas as partes restantes. Esta não é
uma boa escolha. Enquanto você está trabalhando sob o mesmo contrato anterior, sua
programação deve abranger todo o seu escopo. Você deve reagendar as tarefas restantes com
base na nova estratégia em vez de criar um novo plano incompleto. Se você precisa de reportar o
desempenho das tarefas restantes você pode facilmente consegui-lo se tiver um plano completo.

Regras para Agendamento > Regra 2: A programação deve ter todo o escopo


01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19

Regra 3: Tenha cuidado com as tarefas tipo ”level of effort” (definidas pelo esforço)
Existem algumas atividades especiais em todos os projetos que não produzem qualquer produto
por si só têm com função apenas apoiar outras atividades para fazer o seu trabalho.
Gerenciamento de projetos, fiscalização e contabilidade são exemplos deste tipo de atividade.
Essas atividades são chamadas de “level of effort” ou LOE para abreviar.
Alocar LOE’s em um projeto não é tão fácil como qualquer outra tarefa além disto mal fazem
qualquer diferença no processos de monitoramento e controle. É por isso que alguns planejadores
preferem não inseri-las em suas programações. O DoD proíbe sua utilização em alguns casos.
Se você quiser ter um escopo completo em sua programação você tem que inlcuir as LOE’s, e é por
isso que o PMI não as proíbe, mas recomenda que tenha cautela, porque elas nunca devem estar

no caminho crítico.
LOE’s não têm qualquer duração específica e independente, seu início e fim são baseados em
outras atividades. Você nunca jamais atrasaria uma LOE enquanto esta estiver em curso, ela
“trabalha” todos os dias. É por isso que não é aceitável que estejam no caminho crítico. Além
disso, se as suas LOE’s se tornarem-se críticas, algumas outras atividades realmente críticas viriam
a ser não-críticas, e esse é o problema principal. Também é melhor para não ter LOE’s como
antecessores ou sucessores (se o seu software de planejamento o permite).
Se você usar o Primavera P6, você não teria que se preocupar com LOE’s porque P6 tem um tipo
LOE e lida com tudo. Usuários do Microsoft Project deve usar alguns truques para criar LOE’s.

Regras para Agendamento > Regra 3: Tenha cuidado com as tarefas tipo “level of effort”


01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19

Regra 4: Atividades devem ter um nome único
Quando você está nomeando atividades, você deve fazê-lo de uma forma que qualquer pessoa em
qualquer situação poderia entender. Selecione uma atividade, tire-a da WBS e veja se você
consegue entender.
A regra mais importante nesta área é ter nomes exclusivos. Dê uma olhada neste exemplo:

Nomes não são únicos: Nomes são únicos:

Quinto andar Quinto andar
Construir colunas Construir colunas 5º andar
Construir paredes Construir paredes 5º andar
Construir laje Construir laje 5º andar
Sexto andar Sexto andar
Construir colunas Construir colunas 6º andar
Construir paredes Construir paredes 6º andar
Construir laje Construir laje 6º andar
Regras para Agendamento > Regra 4: Atividades devem ter um nome único”


01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19

É preciso mais tempo para escrever os nomes completos e únicos, mas acreditem, vale a pena o
esforço. Você pode facilmente cometer um erro e vincular a laje do sexto andar com outra
atividade, de outro andar, em vez da laje do quinto andar, mas se você usar nomes únicos você
encontrará facilmente os seus erros, ou dificilmente irá cometê-los.

Há sempre muitas maneiras diferentes de exibir as atividades. Você pode fazer estruturas analíticas
alternativas para necessidades diferentes e, nestes pontos de vista você não teria mais elementos
PEP; se os nomes de atividade são únicos, você pode entendê-los mesmo quando fora da WBS,
caso contrário você não seria capaz de usar estruturas de divisão de alternativas de forma

eficiente.

Regras para Agendamento > Regra 4: Atividades devem ter um nome único”


01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19

Regra 5: Nomes de atividades devem ter um verbo
A WBS mostra o escopo. Elementos da WBS são produtos e decompô-los em diferentes tipos de
trabalho é necessários para produzir essas entregas. As atividades são trabalhos que produzem
produtos (elementos WBS).

Como você pode ver, WBS elementos e atividades são duas entidades completamente diferentes.
Esta diferença deve ser refletida em seus nomes.

Dê uma olhada nestes dois nomes:

1. Preparar desenho da loja para a estrutura do segundo andar
2. Desenho da loja para a estrutura do segundo andar

Qual é adequado para elementos PEP e qual é o adequado para as atividades?
A primeira tem uma ação e mostra um trabalho e, portanto, ela pode ser usado para as atividades.
A segunda aponta para algo (no desenho), para um produto e, portanto, ele pode ser usado para
os elementos de PEP. A fim de mostrar um trabalho, você geralmente tem que usar um verbo ou
algo equivalente.

Regras para Agendamento > Regra 5: Nomes de atividades devem ter um verbo


01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19

Regra 6: Cada atividade deve ter pelo menos uma predessessora e uma sucessora
A maioria dos planejadores conhece esta regra:

Cada atividade deve ter pelo menos uma predecessora, exceto a primeira
E
Cada atividade deve ter pelo menos uma sucessora, exceto a última

Quando falamos sobre as atividades, nós queremos dizer atividades e marcos. Se você não
implicam essa regra, algumas das atividades estarão fora da rede e não serão capazes de
influenciar outras atividades ou seria influenciadas por outras, e isso funciona contra a realidade

do trabalho do projeto.

Se você não obedecer à regra, estes seriam os problemas mínimos que iria enfrentar:
• Suas programações futuras não seria realista
• Suas informações de desempenho e análise atrasos não seria realista

É recomendável ter pelo menos dois marcos contratuais em toda programação: o marco inicial e o
marco final. Na maioria dos casos "A data de assinatura do contrato" é o marco de início e "A
aceitação provisória" ou "A aceitação final" é o marco de final. Neste caso, o marco de início não
teria um antecessor,

Regras para Agendamento > Regra 6: Cada atividade deve ter pelo menos uma predessessora e uma
sucessora

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19

E o marco final não teria um sucessor, e todas as outras atividades e marcos necessitariam de pelo
menos um antecessor e um sucessor. Sempre verifique a integridade de sua rede lógica por esta
regra. Se ela falhar, você vai perceber que você perdeu algum dos relacionamentos. É comum para
os planejadores perder os relacionamentos “driven” das atividades (aqueles que não alteram a
programação na fase de planejamento), e você deve ter cuidado com eles.
• Se você acredita que uma determinada atividade ou marco não tem qualquer antecessor (e
pode começar no primeiro dia do projeto), faça do marco inicial sua antecessora;
• Se você acredita que não tem sucessor (e pode terminar no último dia do projeto, e nenhum
outro trabalho vai causar problemas), faça o marco final como sua sucessora

Infelizmente, alguns planejadores sabem esta regra, mas a única coisa que fazem é tornar o marco
inicial como predecessor de todas as atividades que não têm outros antecessores e fazer o marco
final o sucessor de todas as atividades que não têm outros sucessores. Isto é trapaça! Você deve
sempre analisar e encontrar as relações inexistentes. Quando você revisa um planejamento que
você pode facilmente identificar que alguns itens têm muitos antecessores ou sucessores, eles
geralmente apresentam este tipo de trapaça. LOE’s são exceções, você não tem que ter
antecessores e sucessores para eles. Alguns software de planejamento de trabalham bem isto
(como o Primavera P6) e você não tem controle sobre ele (tudo bem). Se você estiver usando
outro software (como o Microsoft Office Project), e você pode evitar relações para LOE’s você deve
tentar fazê-lo.

sucessora

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19

Tudo o que eu já mencionei antes, esta regra é feito pelo PMI. No DoD, você pode ter no máximo
5% das atividades sem predecessores ou sucessores. Antes de terminar esta regra, devo
mencionar a forma como o Microsoft Office Project, e algum software de planejamento se
comportam com os relacionamentos. Neste tipo de software em que você está consegue ter
tarefas de resumo como antecessores e sucessores, neste caso:

• Todos os predecessores de uma tarefa de resumo atuaria como antecessores para todos os
seus filhos.
• Todos os sucessores de uma tarefa de resumo agiria como sucessores para todos os seus filhos.

Como resultado, você pode ter algumas atividades sem relações diretas que herdam suas funções
de tarefa de nível superior (resumo). Esses tipos de antecessores e sucessores também são o
suficiente para esta regra, e você não precisa se preocupar, mas ter em mente que a maioria dos
recursos recomendamos que você não deve usar tais relacionamentos porque eles são mais
difíceis de gerenciar e você pode estar sujeito a muitas erros.

sucessora

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19

Regra 7: A atividade não deve estar ”solta”
Implementar a regra anterior é necessária, mas não é suficiente. A fim de ter um planejamento
dinâmico, vivo e eficaz, o início de cada atividade deve ser influenciado por outras atividades e o
fim desta atividade deve influenciar outras atividades, caso contrário, a atividade seria classificada
como “solta”.

Vejamos este exemplo:

A atividade B tem uma antecessora do tipo FS e um sucessora do tipo SS, e isto é aceitável em
relação à norma anterior (regra número 6). No entanto, o que acontece se a atividade B acabar
com uma atraso grande ? O resultado seria este:

Regras para Agendamento > Regra 7: A atividade não deve ser pendente


01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19

A data final da atividade não influencia em nada nossa programação. É correto isto? Quase todas
as datas finais em um projeto real influenciam de algum modo este projeto, portanto, não parece
normal que tenhamos atividades pendentes. Se você tem uma série de atividades pendentes, você
pode não conseguir fazer programações de tempo realistas e, claro, você não seria capaz de
calcular um intervalo realista.
Segundo o PMI e o DoD esta é a regra para evitar atividades pendentes:

A atividade deve ter pelo menos um antecessor FS ou SS e pelo menos uma sucessora FS ou FF.

Você não é obrigado a não ter quaisquer atividades pendentes, mas é fortemente recomendado
diminuir o seu número, tanto quanto você puder. Creio suas atividades pendentes devme ter um
percentual interior a 1%.
Voltemos à regra, o FS e relações SS influenciarão a data de início das suas sucessoras:

Início de B é influenciada pela O início de B é influenciada pela
predecessora por causa da relação FS. predecessora por causa da relação SS.



01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19

As sucessoras tipo FS e FF serão inlfuenciadas pela data final:

O término da B influencia a O término da B influencia a
sucessora devido à relação de sucessora devido à relação de
FS. FF.

Além de evitar atividades pendentes, há duas outras coisas importantes que percebemos nesta

regra:

• Nos dois cenários o único relacionamento efiicaz é FS. Mais tarde, você vai ver que você deve
tentar usar relações FS na maior parte do tempo. Se você fizer isso você não precisa ter medo
de criar atividades pendentes.
• Você percebeu que um dos quatro tipos de relacionamento não aparece nesta regra? É a SF.
Vamos discutir em outras regras que é melhor evitar relações SF. Esta relação não é eficax nem
para influenciar outras relações nem para ser influenciada.



01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19

Regra 8: A maioria dos relacionamentos deve ser FS
O PMI diz que você deve usar o relacionamento FS para a maioria de suas atividades. A regra do
DoD é que pelo menos 90% das atividades deve ter predecessores FS.
Quando a programação foi modelada com o método do diagrama de setas, existia apenas o
relacionamento FS. Mais tarde, os outros três tipos de relacionamentos surgiram na programação.
O fato é que a maioria das realidades são melhor modeladas com FS.
Alguns planejadores estão acostumados a usar todos os relacionamentos, especialmente SS. O uso
mais comum de SS é quando você encontra a seguinte situação: ... e atividade B começa, ao
mesmo tempo com a atividade ...
Então você faz uma relação SS para B.

Regras para Agendamento > Regra 8: A maioria dos relacionamentos deve ser FS


01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19

Quando você fizer isso, o significa que B não pode iniciar a menos que A tenha começado. É o
caso? Normalmente, não. Quando se diz que B começa ao mesmo tempo que A, geralmente
significa que B tem as mesmas predecessores que A, e como resultado, a escolha correta seria
esta:

Você precisará inserir mais relacionamentos neste caso. Por exemplo, se você tem 16 antecessores
para A, você terá que adicionar todas elas para B. Você também pode usar um marco para isto.
Relacionar todas as antecessoras neste marco e fazer que A e B sejam sucessores deste marco.



01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19

Quando você tem muitos sucessores baseados em uma série de antecessores, você realmente tem
um evento importante e é melhor você criar um marco para isso. Este tipo de marco às vezes é
chamado um marco de pedágio.

Outro exemplo: as atividades A e B têm 10 dias de duração, e atividade B tem uma sobreposição
de 50% com A.

Você pode usar SS +5 dias para B, mas FS-5 dias é um melhor.

Estes foram apenas alguns exemplos da substituição de algumas das relações SS com as melhores
escolhas de FS. Você pode encontrar outros cenários de substituição conforme suas necessidades.
Sempre verifique o número de atividades com relações FS, se elas representam menos de 90% de
todas as atividades sua rede lógica não é boa o suficiente.



01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19

Regra 9: Tente não utilizar relacionamentos SF
O PMI recomenda que você use SF o mínimo possível. O DoD proíbe completamente
relacionamentos SF.
SF é uma estranha relação. A primeira impressão é que essa relação coloca a atividade antes da
sua predecessora.
Por exemplo:

Então, o que acontece se tivermos mais de uma predecessora?

O que as pessoas esperam O que realmente acontece

Algumas pessoas esperam que a sucessora termine antes da primeira predecessora, mas na
realidade termina antes da última predecessora. Uma relação SF diz que a sucessora não deve
terminar que a predecessora começasse, em outras palavras, a sucessora não deve ser anterior a
uma determinada data. Quando você tem três fundos estruturais, isso significa que suas

Regras para Agendamento > Regra 9: Tente não utilizar relacionamentos SF


01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19

Sucessoras devem terminar quando todas as três antecessoras tiverem começado, o que significa
um início mais tardio para todas as antecessoras.
Quando as pessoas começam a aprender sobre planejamento estão sempre tentando encontrar
bons exemplos deste tipo de relação. Um exemplo para isto são as compras. Suponha que nós
temos que construir uma parede e temos que comprar os materiais. Quando devemos comprá-lo?
É possível comprá-lo quando o projeto começa, mas geralmente preferem comprá-lo mais tarde
para não ter que armazenar material por um longo período de tempo. Este exemplo mostra as
atividades baseadas em uma relação SF:

Agora a atividade de compras está agendada para terminar exatamente antes do início da
atividade de construção. É um bom relacionamento, mas o que acontecerá se não conseguirmos
comprar o amterial a tempo? Esta programação mostra o resultado:

Iniciamos a atividade de compras em dia, mas percebemos que levará mais tempo que
pensávamos. Agora, o prazo da construção não mudou, mas é certo? Claro que não, não podemos
iniciar a construção até que a atividade de compras tenha terminado. Uma relação SF não é uma
escolha boa neste caso. Aliás, quando é bom usar SF? Bem, nada! Melhor não usá-la em nada.

Regras para Agendamento > Regra 9: Tente não utilizar relacionamentos SF


01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19

Regra 10: Você não deve utilizar folgas grandes
Imagine um projeto longo, como dois anos e com um relacionamento FS +180 dias, o que significa
isso? Qual a justificativa para uma relação FS que tem que esperar 180 dias desde o início da
predecessora?
Tenho certeza que você não será capaz de dar uma resposta adequada para isso. Não há uma
resposta para longas folgas, não há nada na realidade que você pode modelar com estes tipos de
relacionamentos. Então por que as pessoas ainda os utilizam? A resposta é simples: Elas não
sabem criar relacionamentos suficientemente bons. Por favor, lembre-se que a nossa
responsabilidade não está em criar uma programação estática por um tempo específico, o nosso
objetivo é projetar e construir uma programação viva, dinâmica, que pode produzir programações

significativas o tempo todo.
PMI diz que você deve ter cuidado com folgas e não usá-los em vez de atividades ou
relacionamentos complicados. O DoD proíbe o uso de folgas com mais de 5 dias úteis.
Vamos dar um exemplo: temos uma atividade como “projeto xyz" e uma outra atividade como
“construir xyz" e uma relação de FS +20 dias. Os 20 dias são o tempo necessário para a aprovação
do projeto.

Regras para Agendamento > Regra 10: Você não deve utilizar folgas grandes


01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19

Esta folga não é aceitável nos termos do DoD. Vamos a uma alternativa:

Este esquema é fácil de entender, de gerenciar e não usa folgas para nada.

Outro exemplo: temos uma atividade, como "construir laje, parte 1" e outra como "construir laje,
parte 2". Elas serão construídas uma após a outra, mas usam os mesmos métodos de trabalho e,
como resultado, seria necessária alguma folga para a cura do concreto. Esta seria a escolha alguns

planejadores:

Nós usaremos esta alternativa para evitar uma folga:

Temos uma grande oportunidade neste caso: quanto tempo leva a cura do concreto da laje? Na
verdade, depende da temperatura, e a temperatura em si é dependente da época do ano, vamos
dizer que varie entre 3 e 15 dias



01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19

Podemos colocar algo como 3 * 24 horas para completar esta tarefa e criar um calendário especial
de 24 horas por dia para isto. Este calendário tem 24 horas por dia em estações secas e diminui em
outras estações até chegar a 4 ou 8 horas por dia nas estações chuvosas. Agora, esta atividade de 3
* 24 será automaticamente concluída em 3 dias no outono ou inverno e em 15 dias na primavera
ou verão. Não é ótimo? Este seria o tipo de modelo de programação que chamamos de dinâmico.

O que iríamos implementar com folgas é normalmente uma entidade mais complexa e dinâmica
que deve ser tratada como uma atividade.

Eu não sei se você vai aceitar a regra do DoD, ou não, mas se você não fizer isso eu sugiro que você
deve manter um limite para os seus atrasos; 22 dias úteis, por exemplo, mas nunca use qualquer
tipo de folga simplesmente por sua própria vontade.



01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19

Regra 11: Use folgas o mínimo possível
Como discutimos antes, folgas não são pontos fortes para nossa programação e você deve ter
cuidado com elas. O assunto da regra anterior era a duração da folga, e agora, vamos prestar
atenção ao número de atividades com uma certa folga.

Não é o suficiente limitar o tamanho das folgas se você as tiver utilizando na maioria das
atividades. Não é natural usá-las tanto. Para o DoD a regra é que você não deve usar folgas em
mais de 5% das atividades.

Pense sobre isso. É difícil de implementar? Se você pensa assim, você deve considerar a busca de

mais relacionamentos, adicionando as restrições necessárias (se houver) e, finalmente, dividir suas
atividades para ter mais flexibilidade nos relacionamentos.

Regras para Agendamento > Regra 11: Use folgas o mínimo possível


01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19

Regra 12: Tenha cuidado com os links
PMI trata links com folgas, você deve ter cuidado para não usar links grandes e ao invés disto usar
atividades sempre que possível. O DoD é muito mais rigoroso nesta área e proíbe completamente
o uso destes links.

Por quê? E como?

Bem, a razão é que estes links geralmente são mal utilizados e difíceis de gerir. Em algumas
situações, você começa com uma relação FS, mais tarde, você começa atrasado esta atividade e
você tem que comprimir o cronograma. Você faz essa antiga relação FS em um FS cinco dias. A

mesma coisa acontece e FS-5 dias torna-se FS-10 dias, FS-15 dias e ... você realmente tem uma
estratégia para realizar as sobreposições? Algumas pessoas não têm. Esse é o mau uso que eu
estava falando. Então, isso significa que não devemos usar sobreposições? Não necessariamente.
Vamos verificar este plano de amostragem:

É uma parede que vamos construir e pintar. Não vamos esperar que toda a parede seja concluída
antes de iniciar o trabalho de pintura: queremos sobrepor essas duas atividades. Se você quiser
aceitar a Regra DoD, você pode substituir este agendamento pelo agendamento seguinte.

Regras para Agendamento > Regra 12: Tenha cuidado com os links


01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19

O que fizemos aqui foi quebrar cada atividade em duas novas atividades distintas. Quando a
construção da primeira parte da parede é concluída, a construção da segunda parte e da pintura
da primeira parte começa. Quando a construção da segunda parte e pintura da primeira parte
terminarem inicia a pintura da segunda parte.
Agora, imagine a pintura da primeira parte. Nossa estimativa inicial era de 5 dias, e isso aconteceu
em 2 dias. O que acontece? Este seria o resultado:

Acabamos de entrar com o início real e datas de término, além da duração% concluída, e nenhuma
manutenção estava envolvida. Agora vamos ver o que acontece com a primeira alternativa:



01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19

E sabemos que o nosso progresso real deve ser compatível com a data de status (data date). Neste
caso, a nossa barra de progresso passou a data de status e não é aceitável. O que devemos fazer?
Devemos alterar a duração da pintura? Este seria o resultado:

E isto não é aceitável; nossa pintura acabou antes mesmo de construir a parede. Aqui está a outra
alternativa

Esta ainda não é boa o bastante, porque usa divisão de tarefa. Eis outra alternativa:

Isto não é aceitável porque nos diz que pintaríamos as paredes, nos próximos três dias, mas vamos
ser capazes de realizar sito?
Este exemplo mostra o que eu disse antes, que os cronogramas que utilizam links grandes são mais
difíceis de gerir.



01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19

E finalmente, a pergunta que sempre me faço: Você aplicaria esta regra a voê mesmo?

Não, eu não. É uma ótima regra, mas muito difícil de se aqplicar. Eu uso minha própria regra:

Use links grandes o mínimo possível, e se tiver que usá-los, evite links com mais de 22 dias úteis.

Se você acredita que precisa mesmo usar este tipo de link, especialmente os links com grandes
folgas, talvez você precise reconsiderar o design das suas atividades.



01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19

Regra 13: Tenha cuidado com as folgas negativas
Esta é uma regra do DoD e não tem equivalência no PMI.

Há dois tipos de agendamento; Vou chamá-los de agendamentos livres e agendamentos fixos.

Nos agendamentos fixos, você aponta todos os seus marcos contratuais e restrições inflexíveis. Por
exemplo, se você tem que terminar um projeto em 21 de maio de 2014, você deve adicionar uma
retrição como “Não terminardepois de 21 de maio de 2014” ou “Terminar antes ou até 21 de maio
de 2014”, para seu marco final. Neste caso você mesmo que você esteja atrasado sua data d
etérmino ainda seria 21 de maio de 2014, mas você teria unma folga negativa. Se você tem uma

folga negativa, digamos de 50 dias, isto significa que você terminará seu projeto 50 dias após o seu
marco contratual final.

Em agendamentos livre, você não deve entrar com qualquer tipo de restrição inflexível. Neste
caso, sua data final do projeto mudará regularmente, e você deverá verificar isto o tempo todo
com sua linha de base. Por exemplo, a data de término para o seu projeto pode ser 10 de julho de
2014, e a variação entre esta data e a linha de base (21 de maiode 2014) seria de 50 dias, e neste
caso você perceberia que seriam 50 dias de atraso.

Os dois métodos são válidos e cada um tem seus prós e contras. Os agendamentos livres são mais
comuns e fáceis de gerenciar.
Regras para Agendamento > Regra 13: Tenha cuidado com as folgas negativas


01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19

Se você terminar seu planejamento inicial e tiver uma folga negativa em um agendamento fixo,
seria similar a ter um agendamento livre com uma data final que não é compatível com a data final
contratual; este é o motivo que folgas negativas ão são aceitáveis

Já foi visto que alguns planejadores não tem tempo suficiente para comprimir o cronograma, e
eles tem que emitir a programação. Alguns deles usam truques tipo “Não terminar depois de”ou
Terminar em ou antes de” como marco restritivo. Neste caso, o agendamento parece compatível
com o contratual, mas uma folga negativa mostrará o problema.

Regras para Agendamento > Regra 13: Tenha cuidado com as folgas negativas


01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19

Regra 14: As atividades não devem ter folgas grandes
Você não tem nenhum controle diretamente sobre as folgas. Folgas grandes são justamente o
sintoma de relacionamentos frágeis.
Verifique as folgas entre as atividades; se elas forem maiores que o esperado talvez seja porque
você tenha esquecido de algo. Talvez alguns links não tenham sido feitos, talvez eles estejam
erados, etc..
Em termos do DoD você não pode ter folgas maiores que 44 dias úteis (doi smeses nos
calendários). Se isto ocorrer você deve voltar e revisar todos os seus elementos de agendamento e
descobrir o problema. O problema mais comum é não adicionar tarefas drivers nos

relacionamentos. Dê uma olhada neste planejamento:

A barra amarela mostra a folga total. As atividades Be E têm folgas e a outras são críticas. A
atividade B tem uma folga grande, mas porque? B terminou no início do e não tem sucessoras,
exceto o marco final. O que aconteceria se B não terminasse antes do último dia? Quando nós nos
perguntamos isto, podemos perceber que D é a sucessora
Regras para Agendamento > Regra 14: As atividades não devem ter folgas grandes


01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19

Nós não adicionamos D como sucessora de B, até porque elas estão distantes, e temos certeza que
B terá terminado antes de D começar. Este tipo de relacionamento é o chamado non-driving. Se
adicionarmos o relacionamento o agendamento pode não mudar, mas teremos uma folga mais
realista para B:

Quando a atividade tem múltiplas sucessoras, cada uma delas tem tendências específicas para
empurrar a atividade para datas posteriores. Mas uma delas tem uma tendência maior e por isto é
chamada de driving. Se você apagar todos os outros relacionamentos sua predecessora não se
moverá, mas você terá dois problemas:
• As folgas não serão realísticas. Quando você apagar um relacionamento non-driving a folga da
antecessora pode aumentar.
• Drivers sempre mudarão. Um relacionamento pode ser o driver hoje, mas amanhã, depois de
atualizar o agendamento, outro relacionamento pode ser o driver. Todos os relacionamentos
on-driving tem potencial para sê-lo um dia, e se você não adicioná-los me seus agendamentos
e avaliações futuras, talvez não esteja sendo realista.
Então sempre verifique os cenários e todas as possibilidades, mesmo que não sejam drivers.
Regras para Agendamento > Regra 14: As atividades não devem ter folgas grandes


01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19

Regra 15: Não divida atividades
A maioria dos softwares de planejamento tem um recurso para divisão de atividades, mas isto não
significa que você tem que dividir suas atividades!

O PMI proíbe a divisão de atividades, porque atividades divididas são difíceis de gerenciar e você
não pode implementar uma lógica efetiva para isto.

Sempre que você quiser dividir uma atividade, pense que você deva ter que quebrá-la em duas ao
invés disto.

Split activity

Relationship to the cause of the pause

Two separate activities
instead of splitting

Por que você deve realmente dividir uam atividade? A atividade inicia, continua, e então precisa de
uma pausa antes que algo aconteça. Este “algo mais”é que você deve ter em seus planos; você não
pode simplesmente aplicar esta lógica em uma atividade dividida, mas pode fazê-lo quando quebra
em duas atividades distintas.

Regras para Agendamento > Regra 15: Não divida atividades


01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19

Dividindo, usualmente é isto que acontece quando você reprograma o cronograma. Por exemplo:

Dividindo o que acontece quando você reprograma o cronograma? A resposta depende do seu
softwre de planejamento e suas preferências, mas a resposta mais comum é por exemplo:

Este não é um bom resultado. Neste caso, a raiz do problema é como você atualizou seu
cronograma. Veja a atividade B; o seu progresso é compatível com a data d estatus (a barra de
progresso é tão grande quanto a data de status), mas há algo d eerrado com a atividade A. Talvez a
data de início atual ão esteja correta, e sua atualização pode se parecer com isto:



01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19

Ou, talvez, a data atual de início esteja correta, mas você terá que revisar a duração restante:

Eu não vou discutir processos de atualização e requisitos, mas vou lembrá-lo que conforme o PMI
e o DoD, você deve entrar com estes dados para cada período atualizado:

• Início atual (se já foi iniciado)
• Término atual (se já foi terminado)

• Duração atual e restante (se estiver em andamento)

Se você entrar com estes dados corretamente, suas atividades não serão divididas quando
reprogramar.



01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19

Regra 16: Não utilize muitas restrições de data
Restrições d edata não são dinâmicas, e você não encontrará restrições de data reais na maioria
dos projetos. Alguns planejadores usam isto ao invés de relacionamentos, isto é errado.

O PMI diz que voc6e deve ter muito cuidado e não usar restrições de tada no lugar de
relacionamentos.

O DoD diz que as atividades com restrições inflexíveis não devem ser mais de 5% das atividades.

O que o DoD que rdizer com retrições rígidas são “Não terminar depois de” ou “Terminar em ou

antes de” que evitam que as atividades vão para datas posteriores.

Como mencionado antes, você provavelmente nem irá precisar de usar restrições de datas na
maioria dos projetos. As vezes, uma limitação pode parecer uma restrição, mas é na verdade outro
elemento d eprogramação (usualmente um relacionamento, ou um cakendário propriamente).
Vamos supor que o gerente de projetos diga que a atividade X não pode iniciar antes de uma
determinada data; qual restrição você utilizaria para isto? Bem, não muitas. Você deve verificar a
razão por trás desta restrição de data. Talvez tenha algo a ver com o clima, as estações (como
trabalhar ou não no verão), e você deve ser capaz de fazer um calendário separado para estas
atividades e suas limitações, em vez de usar uma restrição.

Regras para Agendamento > Regra 16: Não utilize muitas restrições de data


01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19

Regra 17: Crie milestones (marcos) para restrições de data
Esta não é uma regra do PMI ou do DoD; esta é minha própria regra a qual eu acho muito útil e
vou compartilhar com você.

Restrições de tada em especial; elas refletem eventos importantes em nossos cronogramas.
Estamos acostumados a ver eventos como marcos, então por que não limitar restrições de data
para marcos?

Vamos supor que tenha uma atividade. Você não pode começar por causa de uma
regulamentação. E esta regulamentação diz que você só pode começar depois de 1° de favereiro.

O que você provavelmente vai fazer é atribuir uma restrição tipo “Não iniciar antes de 1° de
favereiro” ou “Iniciar até 1° de favereiro ou antes”. Eu prefiro não atribuir nenhuma restrição rígida
de data a nenhum aatividade. Em vez disso, eu faço um novo marco chamado "data de início Legal
de ...", e atribuo uma restrição para esse marco tornando a atividade original em uma sucessora do
novo marco.

Neste cenário, você vai sempre lembrar o evento quando você olhar para o calendário porque
marcos são muito mais visíveis do que as restrições. Alterar a data de restrição também será muito
mais fácil, especialmente quando você usá-la para mais de uma atividade. É sempre melhor você
ter um elemento na WBS (ou uma tarefa resumo) para seus marcos contratuais e gerenciais no
início dos cronogramas e não colocá-los ao lado de outros marcos.
Regras para Agendamento > Regra 17: Crie milestones (marcos) para restrições de data


01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19

Regra 18: Atividades não devem ter durações muito longas
É sempre uma longa história sobre quão detalhadas nossas atividades devem ser. Você talvez
tenha problemas para monitorá-las, e deve ser muito difícil projetar uma rede de relacionamentos
se não suficientemente detalhada. E se for extremamente detalhada gastará muito tempo
monitorando e controlando.
O caso é que se você colocar bastante atividades você não perderia tanto quanto se colocasse
poucas. É por isto que o PMI eo DoD concentram-se tanto nas durações máximas e não no mínimo
permitido.
A duração máxima admitida pelo DoD é de 44 dias úteis, equivalente a dois meses pelo calendário.
Os 44 dias úteis parecem ser uma boa escolha, mas como seria num projeto com duração de 4

meses? 44 dias úteis parecem muito para um projeto deste. É por isto que o PMI usa um
parâmetro. O PMI diz que você não deve ter nenhuma duração maior que dois períodos d
econtrole em qualquer atividade. Então se tiver um projeto regular que dure 2 anos e o seu
per[iodo d econtrole é de 1 mês, então a duração máxima permitida seria de 2 meses; mas se tiver
um projeto que dure 4 meses então deve querer controlar ele semanalmente, então sua duração
máxima permitida seria de 2 semanas.
A regra do PMI aplica-se sobre atividades normais, não sendo portanto aplicáveis a regras
definidas pelo esforço. O DoD diz que você não deve ter mais que 5% das atividades de um projeto
com duração máxima permitida (44 dias úteis).

Regras para Agendamento > Regra 18: Atividades não devem ter durações muito longas


01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19

Regra 19: Utilize apenas uma unidade de duração
Existem muitas unidades de tempo diferentes; dias semanas, meses, anos, horas e minutos. How
você utiliza todas elas?

A unindade mais comum é o dia, mas os planejadores as veze sprecisam utilizar mais unidades
além destas. Por exemplo, a maioria das atividaddes tem duração prevista em dias, mas algumas
outras são baseadas em meses ou horas.

O DoD recomenda que você utilize apenas uma unidade de duração. Isto facilita o agendamento

Regras para Agendamento > Regra 19: Utiliza apenas uma unidade de duração


Regras Para Agendamentos De Atividades Em Projetos

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Mehr von Wladmir Araujo

Mehr von Wladmir Araujo (12)

Regras Para Agendamentos De Atividades Em Projetos