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

http://br.linkedin.com/in/wladmiraraujo

wla

dm

ir_a

rau

jo@

ho

tmai

l.co

m –

31

91

57

-17

77

Regras para agendamento de atividades em projetos

Regras gerais de acordo com o PMI e DoD

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

mailto:[email protected]

http://en.khorramirad.info/


wla

dm

ir_a

rau

jo@

ho

tmai

l.co

m –

31

91

57

-17

77

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

Copyright © 2012 Nader Khorrami Rad

All rights reserved. This material may be freely copied and distributed, in part or as a whole, subject to inclusion of the Author’s name and web address ( www.khorramirad.info ). While all attempts have been made to verify information provided in this publication, the Author assumes no responsibility for errors or contrary interpretation of the subject matter herein. The author has tried to be as objective as possible but might have been influenced by his personal experiences and preferred practices. Translated of material from english to brazillian portuguese by Wladmir Araujo

Todos os direitos reservados. Este material pode ser livremente copiado e distribuído, em parte ou como um todo, sujeito à inclusão do nome do autor e endereço web (www.khorramirad.info). Embora todas as tentativas foram feitas para verificar as informações prestadas nesta publicação, o autor não assume qualquer responsabilidade por erros ou interpretação contrária do assunto aqui tratado. O autor tentou ser o mais objetivo possível, mas pode ter sido influenciado por suas experiências pessoais e práticas preferidas. Tradução do material fornecido do inglês para o português brasileiro realizada por Wladmir Araujo



http://www.pmarchy.com/


http://www.khorramirad.info/










wla

dm

ir_a

rau

jo@

ho

tmai

l.co

m –

31

91

57

-17

77


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 [email protected]. Eu ficaria feliz em ter o seu feedback; por favor contacte-me através [email protected] 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 este e-book















wla

dm

ir_a

rau

jo@

ho

tmai

l.co

m –

31

91

57

-17

77


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.

Sobre o autor





wla

dm

ir_a

rau

jo@

ho

tmai

l.co

m –

31

91

57

-17

77


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.

Introdução

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.

Escopo deste e-book





wla

dm

ir_a

rau

jo@

ho

tmai

l.co

m –

31

91

57

-17

77


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.

Fontes





wla

dm

ir_a

rau

jo@

ho

tmai

l.co

m –

31

91

57

-17

77


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




wla

dm

ir_a

rau

jo@

ho

tmai

l.co

m –

31

91

57

-17

77


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

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

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.

Regra 1: Documentar a Metodologia de programação




wla

dm

ir_a

rau

jo@

ho

tmai

l.co

m –

31

91

57

-17

77


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

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

Plano de gerenciamento do tempo

Modelo de programação & programação

Monitoramento e controle

Execução

Controle integrado de mudanças




wla

dm

ir_a

rau

jo@

ho

tmai

l.co

m –

31

91

57

-17

77


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

Regras para Agendamento > 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.

Regra 2: A programação deve ter todo o escopo




wla

dm

ir_a

rau

jo@

ho

tmai

l.co

m –

31

91

57

-17

77


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

Regras para Agendamento > 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.

Regra 2: A programação deve ter todo o escopo




wla

dm

ir_a

rau

jo@

ho

tmai

l.co

m –

31

91

57

-17

77


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

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

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.

Regra 3: Tenha cuidado com as tarefas tipo ”level of effort” (definidas pelo esforço)




wla

dm

ir_a

rau

jo@

ho

tmai

l.co

m –

31

91

57

-17

77


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

Regras para Agendamento > 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:

Regra 4: Atividades devem ter um nome único

Nomes não são únicos: Quinto andar Construir colunas Construir paredes Construir laje Sexto andar Construir colunas Construir paredes Construir laje

Nomes são únicos: Quinto andar Construir colunas 5º andar Construir paredes 5º andar Construir laje 5º andar Sexto andar Construir colunas 6º andar Construir paredes 6º andar Construir laje 6º andar




wla

dm

ir_a

rau

jo@

ho

tmai

l.co

m –

31

91

57

-17

77


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

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

É 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.




wla

dm

ir_a

rau

jo@

ho

tmai

l.co

m –

31

91

57

-17

77


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

Regras para Agendamento > 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.

Regra 5: Nomes de atividades devem ter um verbo




wla

dm

ir_a

rau

jo@

ho

tmai

l.co

m –

31

91

57

-17

77


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

Regras para Agendamento > 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,

Regra 6: Cada atividade deve ter pelo menos uma predessessora e uma sucessora




wla

dm

ir_a

rau

jo@

ho

tmai

l.co

m –

31

91

57

-17

77


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.




wla

dm

ir_a

rau

jo@

ho

tmai

l.co

m –

31

91

57

-17

77


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.




wla

dm

ir_a

rau

jo@

ho

tmai

l.co

m –

31

91

57

-17

77


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

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

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:

Regra 7: A atividade não deve estar ”solta”




wla

dm

ir_a

rau

jo@

ho

tmai

l.co

m –

31

91

57

-17

77


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 predecessora por causa da relação FS.

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




wla

dm

ir_a

rau

jo@

ho

tmai

l.co

m –

31

91

57

-17

77


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: 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.

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

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




wla

dm

ir_a

rau

jo@

ho

tmai

l.co

m –

31

91

57

-17

77


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

Regras para Agendamento > 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.

Regra 8: A maioria dos relacionamentos deve ser FS




wla

dm

ir_a

rau

jo@

ho

tmai

l.co

m –

31

91

57

-17

77


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.





wla

dm

ir_a

rau

jo@

ho

tmai

l.co

m –

31

91

57

-17

77


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.





wla

dm

ir_a

rau

jo@

ho

tmai

l.co

m –

31

91

57

-17

77


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

Regras para Agendamento > 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:

Regra 9: Tente não utilizar relacionamentos SF

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




wla

dm

ir_a

rau

jo@

ho

tmai

l.co

m –

31

91

57

-17

77


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

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

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.




wla

dm

ir_a

rau

jo@

ho

tmai

l.co

m –

31

91

57

-17

77


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

Regras para Agendamento > 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.

Regra 10: Você não deve utilizar folgas grandes




wla

dm

ir_a

rau

jo@

ho

tmai

l.co

m –

31

91

57

-17

77


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




wla

dm

ir_a

rau

jo@

ho

tmai

l.co

m –

31

91

57

-17

77


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.




wla

dm

ir_a

rau

jo@

ho

tmai

l.co

m –

31

91

57

-17

77


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

Regras para Agendamento > 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.

Regra 11: Use folgas o mínimo possível




wla

dm

ir_a

rau

jo@

ho

tmai

l.co

m –

31

91

57

-17

77


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

Regras para Agendamento > 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:

Regra 12: Tenha cuidado com os links

É 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.




wla

dm

ir_a

rau

jo@

ho

tmai

l.co

m –

31

91

57

-17

77


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:





wla

dm

ir_a

rau

jo@

ho

tmai

l.co

m –

31

91

57

-17

77


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.





wla

dm

ir_a

rau

jo@

ho

tmai

l.co

m –

31

91

57

-17

77


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.





wla

dm

ir_a

rau

jo@

ho

tmai

l.co

m –

31

91

57

-17

77


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

Regras para Agendamento > 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.

Regra 13: Tenha cuidado com as folgas negativas




wla

dm

ir_a

rau

jo@

ho

tmai

l.co

m –

31

91

57

-17

77


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

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

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.




wla

dm

ir_a

rau

jo@

ho

tmai

l.co

m –

31

91

57

-17

77


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

Regras para Agendamento > 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:

Regra 14: As atividades não devem ter folgas grandes

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




wla

dm

ir_a

rau

jo@

ho

tmai

l.co

m –

31

91

57

-17

77


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

Regras para Agendamento > Regra 14: As atividades não devem ter folgas grandes

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.




wla

dm

ir_a

rau

jo@

ho

tmai

l.co

m –

31

91

57

-17

77


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

Regras para Agendamento > 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.

Regra 15: Não divida atividades

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.

Split activity

Two separate activities instead of splitting

Relationship to the cause of the pause




wla

dm

ir_a

rau

jo@

ho

tmai

l.co

m –

31

91

57

-17

77


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:




wla

dm

ir_a

rau

jo@

ho

tmai

l.co

m –

31

91

57

-17

77


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.




wla

dm

ir_a

rau

jo@

ho

tmai

l.co

m –

31

91

57

-17

77


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

Regras para Agendamento > 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.

Regra 16: Não utilize muitas restrições de data




wla

dm

ir_a

rau

jo@

ho

tmai

l.co

m –

31

91

57

-17

77


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

Regras para Agendamento > 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.

Regra 17: Crie milestones (marcos) para restrições de data




wla

dm

ir_a

rau

jo@

ho

tmai

l.co

m –

31

91

57

-17

77


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

Regras para Agendamento > 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).

Regra 18: Atividades não devem ter durações muito longas




wla

dm

ir_a

rau

jo@

ho

tmai

l.co

m –

31

91

57

-17

77


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

Regras para Agendamento > Regra 19: Utiliza 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

Regra 19: Utilize apenas uma unidade de duração




Documents

Regras Para Agendamentos De Atividades Em Projetos