Menu
Esqueceu a senha? Fazer cadastro

Análise Quantitativa Usando @Risk

No post anterior, vimos um pouquinho da análise quantitativa. Trata-se de um vasto campo de estudo, incluindo diversas ferramentas e técnicas, tais como Valor Esperado, Árvores de Decisão e Simulações Monte Carlo.

Screen Shot 2014-06-02 at 15.19.30

Figura 1 – Ferramentas da análise quantitativa de riscos em projetos

O assunto principal do post anterior foi a simulação Monte Carlo (leia esse .PDF). Algumas outras referências sobre o assunto estão a seguir:

No próximo post, vamos discutir gerenciamento de projetos de Pesquisa, Desenvolvimento e Inovação (PD&I) e o uso de multimetodologias em gerenciamento de projetos. Até lá!

Cálculo do Desvio de Prazo


Através da colaboração de Paulo André, tradutor do livro Earned Schedule para o Português (Prazo Agregado), nesta postagem apresentamos uma explicação simplificada sobre o mecanismo de cálculo da Variação de Prazo.

Também aqui estamos introduzindo um software (de uso gratuito) para auxiliar na geração de relatórios em função de Valores Planejados, Valores Realizados e o Desvio de Prazo.

Estamos aqui criando uma convenção para diferenciar “Variação de Prazo” e o “Desvio de Prazo”, ambos calculados a partir do Método do Prazo Agregado:

  • Variação de Prazo: É a diferença em tempo entre o “Prazo Agregado” e o “Tempo Real”:  VP = PA-TR
  • Desvio de Prazo: É a diferença entre o “Tempo Real” e o “Prazo Agregado”: DP = TR-PA
  • Em outras palavras, VP = -1 x DP.
  • A diferença na aplicação destas duas definições pode ser vista em: http://gestaodeprojetos.com.br/variacao_ou_desvio_prazo/
Desvio e Variação de Prazo  (DP = -1 x VP)

Desvio e Variação de Prazo (DP = -1 x VP)


 Prazo Agregado (Earned Schedule)

http://earnedschedule.com/Images/HowitWorks.jpg


Nas postagens anteriores, fiz uma apresentação sobre a utilização do Prazo Agregado e do Desvio de Prazo Agregado para o desenvolvimento de Indicadores de Projeto, além de uma rápida demonstração de quais são as vantagens de sua aplicação quando comparada a análises convencionais de registros de valores Planejados x Realizados.

Se ainda não conhece as postagens, a sugestão é que comece por elas:

  1. DESVIO DE PRAZO ATRAVÉS DO PRAZO AGREGADO
  2. A CURVA-S, VERSÃO 2.0 (INDICADORES DE PLANEJADO X REALIZADO)

 Explicação sobre o cálculo do Prazo Agregado (PA)
(por Paulo André de Andrade)

2014-05-30 16_06_48-Detalhes do cálculo do Prazo Agregado (1).pdf

Etapas

1. Definir para qual período se deseja conhecer a situação do projeto no que concerne ao Prazo Agregado. Este perído será denominado “TR”.

  • Na literatura “TR” significa “Tempo Real” (tradução do inglês para “Actual Time”) e é associado à data em que o relatório de status é solicitado.
  • Usaremos, por extensão, esse mesmo conceito pressupondo que relatórios teriam sido pedidos a cada período. Assim ao se solicitar um relatório para, por exemplo: o período 7; considera-se o status do projeto neste período, como se os períodos posteriores ainda não tivessem ocorrido.

2. Estabelecer em que período se situa o Prazo Agregado.

  •  Comparar o Valor Agregado (VAcum) com os pontos utilizados para construir a curva do Valor Planejado para determinar o período em que ocorre a seguinte relação: VPi ≤ VA < Vpi+1
  •  O valor de i é o período em que o PA se situa. Assim o Prazo Agregado será Pi + x (x é uma fração de período). Na figura acima i = 4.

3. Calcular o valor de x;

  •  O cálculo do valor de x é feito por semelhança de triângulos como indicado no retângulo realçado na figura acima e expandido abaixo.

2014-05-30 16_37_20-Detalhes do cálculo do Prazo Agregado (1).pdf

  •  O cálculo recorre à seguinte proporção:

2014-05-30 16_37_35-Detalhes do cálculo do Prazo Agregado (1).pdf

a) (P5 – P4) é o tempo de um período conforme definido no projeto e o valor de x será expresso com uma fração deste perído;
b) O valor de “d” é a diferença entre o Valor Agregado (VAcum) e o Valor Planejado para o período “i” ou seja VPi (d = VAcum – VPi)
c) O valor de “c” é a diferença entre VPi+1 e Vpi (c = Vpi+1 – Vpi)

Então:2014-05-30 16_37_46-Detalhes do cálculo do Prazo Agregado (1).pdf

Um alerta: O cálculo da Variação de Prazo (tempo) (VPRt) é dado pela seguinte equação:

VPRt = PA – TR

  • a ordem em que as parcelas “PA” e “TR” são colocadas é importante, pois se o resultado da subtração for negativo indica que o projeto está atrasado caso contrário o projeto está conforme o plano ( VPRt = 0) ou adiantado ( VPRt > 0).

2014-05-30 16_50_35-Detalhes do cálculo do Prazo Agregado (1).pdf


Simplifique o cálculo com um Software Gratuito (em desenvolvimento)

O Prazo Agregado tem um conceito simples e uma aplicação poderosa.

O cálculo do Prazo Agregado, no entanto, pode ser difícil de manter em planilhas pois requer a avaliação de uma etapa do projeto em relação a um histórico onde é necessário identificar entre dois períodos conhecidos um novo valor. A alternativa então é aplicar a fórmula com o uso de um software.

O que faz o aplicativo?

  1. Permite a análise de 3 curvas pré-configuradas, chamadas de Demo1, Demo2 e Demo3 que serão explicadas nas próximas postagens;
  2. Permite a análise de uma Curva-S qualquer de um projeto de sua escolha, desde que cumpra alguns pré-requisitos:
    • Os dados devem estar tabulados (COPY + PASTE a partir de Células do EXCEL);
    • A primeira linha deve conter os PERÍODOS,  numerados de 1 a n;
    • A segunda linha deve conter os VALORES PLANEJADOS;
    • A terceira linha deve conter os VALORES REALIZADOS;
    • A primeira coluna contém um nome para os dados;
    • Todas as demais colunas só possuem valores numéricos.
Exemplo de Cálculo Automático com o Software

Exemplo de Cálculo Automático com o Software


Instruções de Uso:

  1. Estarão em breve disponíveis no próprio aplicativo, que chama uma página de ajuda on-line.
  2. Para os primeiros usuários, aguardo o seu contato via SKYPE para apresentar os macetes deste aplicativo, ainda em sua fase de testes.
  3. Skype: petersmello

 Baixe o aplicativo


 

 

Escreva para petersmello@gmail.com

 

 

 

Análise Quantitativa de Riscos em Projetos

O gerenciamento de riscos, dada a sua importância, já foi assunto de outros posts no Blog. Dêem uma olhada em:

Conversando com gerentes de projetos e especialistas em gerenciamento de riscos, observo frequentemente um grande gap na efetiva utilização de ferramentas da análise quantitativa de riscos. Muita gente já ouviu falar das análises quantitativas, mas existe um estigma de que se trata de algo difícil, caro e demorado de fazer. Não é verdade.

Se não formos capazes de utilizar análises quantitativas, podemos estar colocando muitos recursos em risco desnecessariamente. No post Enganados pela Viabilidade, levantamos questões sobre os estudos de viabilidade e a maneira como são conduzidos.

Segundo Daniel Kahneman, em seu livro Rápido e Devagar, somos extremamente otimistas. Ele cita alguns exemplos. Quando questionados, a grande maioria dos empreendedores mostra confiança em seus negócios (ou plano de negócios), embora a taxa de fracasso seja da ordem de 80%. Em entrevistas com alunos de Harvard, algo em torno de 65% dos alunos afirmam estar “acima da média”.

O próprio Kahneman relata sua experiência com “otimismo exacerbado” no planejamento de projetos. Ele participava de um projeto acadêmico com o objetivo de criar um novo curso e um livro para ser utilizado neste curso, de análise de decisões. No grupo haviam outros professores e pesquisadores eminentes. Quando foram fazer um brainstorming para avaliar as expectativas quanto ao término do projeto, obtiveram um mínimo de 1,5 anos e um máximo de 2,5 anos. Então, Kahneman perguntou a um dos membros do grupo, que já havia observado outras equipes de pesquisa na criação de cursos e livros, qual era a performance dessas equipes. Simples, benchmarking. O professor, que havia estimado terminar o projeto em 2 anos, começou a pensar. Observando o histórico, chegou à conclusão que, em média, essas equipes demoraram 7 anos para concluir um projeto semelhante! E a taxa de fracasso era maior que 70%! Além disso, na mesma análise, a equipe atual deles era menos capacitada que aquelas com as quais eles estavam se comparando…

Já pensou nisso? De onde vem as suas estimativas? Essa é a primeira pergunta fundamental a ser feita.

Existem ferramentas e workshops para calibrar a “opinião dos especialistas” (Subject Matter Experts), tais como os disponíveis em How to Fix Risk Management.

Uma ferramenta simples para obter estimativas é a eliminação.

Por exemplo, você sabe quanto mede a envergadura das asas de um Boeing 747-800? Você provavelmente já viajou em um desses pela Gol, não é? Se você não é um fã de aviões, vai responder que não faz idéia de quanto mede a envergadura. Comece a se questionar quanto ao limite inferior. É possível ter 10m de envergadura? É possível ter 50m de envergadura? 10 metros parece muito pouco, não? Então ficamos com 50m, algo razoável. Agora vamos definir o limite superior, também por eliminação? Será que é possível ter 100m? (um quarteirão só de asas??). Deve ser um pouco menos, vamos chutar 70m. Pronto, conseguimos uma estimativa (mesmo que pouco confiável).

À medida que você for capaz de armazenar o histórico das estimativas dos especialistas e mostrar para eles seu grau de acerto, um processo de calibragem pode ser estabelecido. Veja mais no livro do Douglas Hubbard. O fato é que, para quem não sabe nada, saber pouco é um grande avanço… (por curiosidade, a envergadura do 747-800 é 68,5 metros).

Agora vamos às análises quantitativas, uma vez que você possui boas estimativas, o passo seguinte é modelar a probabildiade e o impacto dos riscos nos objetivos do projeto (cronograma e orçamento).

Análise Monte Carlo

É umaferramenta para combinar distribuições de probabilidades nas variáveis de um modelo por meio de simulacão. Utiliza geração a leatória de valores em vez de cálculos com valores determinísticos. Ou seja, em vez de você ter um valor único para cada variável, teremos uma distribuição de valores.

Screen Shot 2014-05-21 at 22.57.47

Figura 1 – Monte Carlo

Como resultado das simulações, teremos uma distribuição dos resultados, tais como duração do projeto e custo total. É possível ainda fazer outras análises, como análise de sensibilidade (Diagramas de Tornado) e intervalos de confiança, conforme veremos no próximo post. Enquanto isso, leaim esse .PDF sobre abordagem determinística e simulações em projetos de investimento. E, para aqueles que tiverem maior paciência (e interesse), vejam esse video.

Na próxima semana, veremos um tutorial para utilizar o @Risk, realizar simulações e interpretar seus resultados. Até lá!

Aplicando o Caminho Crítico Completo


Após longos debates em diferentes listas de discussão  (enquanto alguns pensam que estamos apenas tratando da semântica de um termo), esta postagem descreve a importância e aplicação do Caminho Crítico Completo (CCC).

Não devemos confundir o CCC com o “Caminho Crítico” na aplicação do termo para o “Método do Caminho Crítico” (CPM), ou para o “Método do Caminho Crítico de Recursos” (RCP) ou mesmo em “Corrente Crítica” (CCPM).

O CCC é sinônimo de “Caminho Crítico do Projeto“, ou “A sequência mais longa de um projeto, do seu início ao término, que determina o menor prazo de um projeto“.

Exemplos de como o CCC é diferente da pura aplicação do termo “Caminho Crítico” estão neste link.


Para os exemplos a seguir, acesse o arquivo original em MPP por este link: http://1drv.ms/1jqcexL

1. Identificando o Caminho Crítico (CPM)

1. Onde Está o Caminho Crítico Completo ?

1. Caminho Crítico CPM: Onde Está o Caminho Crítico Completo ?

A ilustração (1) contém um Cronograma com apenas 16 atividades que foram inicialmente relacionadas entre si em função de uma rede lógica (Método do Caminho Crítico). Para cada atividade de programação, temos uma atividade de testes correspondente. Durações e recursos forma adicionados também a este cronograma.  Após a sua elaboração também foi gravada uma Linha de Base.

Embora o software nos calcule as datas de início e término (15/04/2014 a 21/04/2014), ao ativarmos o “Gantt de Controle” que deveria nos mostrar:

  •  Atividades em suas datas atuais (em azul ou vermelho)
  • Atividades em suas datas originais (linha de base, em cinza);
  • Caminho Crítico (atividades em vermelho)

No entanto, ao examinarmos o conjunto de atividades “em vermelho”, nós não conseguimos atender a definição de Caminho Crítico do Projeto, ou Caminho Crítico Completo:

  •  “A sequência mais longa de um projeto, do seu início ao término, que determina o menor prazo de um projeto

Isso ocorre pois – embora o software nos permita calcular o cronograma com base a disponibilidade de recursos – neste caso ele nos apresenta o “caminho crítico” calculado exclusivamente pelo CPM (Critical Path Method, ou Método do Caminho Crítico).

 Na concepção original de CPM, o “caminho crítico é a sequência de atividades com folga zero”, de tal forma com que o atraso em uma de suas atividades representem um atraso no projeto. Pelo o que podemos observar na aplicação do método em um cronograma nivelado por recursos, o caminho apresentado é composto exclusivamente pelas atividades 21 e 23, que tem “folga” ou “margem de atraso total” igual a zero.

2 – Identificando o Caminho Crítico (RCP)

2 - Caminho Crítico em RCP (Resource Critical Path)

2 – Caminho Crítico RCP (Resource Critical Path): Onde está o Caminho Crítico Completo?

Ao analisarmos as mesmas atividades em uma ferramenta que seja capaz de identificar folgas em função de nivelamento de recursos (Spider Project e Primavera são duas sugestões),  podemos verificar que temos mais algumas atividades que deveriam pertencer ao Caminho Crítico do Projeto.

No entanto, nesta solução de nivelamento que foi realizada no MS-Project e transferida para o Spider, temos dois elementos fundamentais que indicam que pode haver uma oportunidade de otimização deste cronograma: A folga total e a folga total de data de término.

A existência de atividades com folga, quando estamos buscando identificar o Caminho Crítico Completo, pode ser um indicativo de:

A) Dependência externa: Uma restrição do tipo “Não Inciar Antes de”, indicando uma necessidade externa (uma autorização de trabalho, por exemplo).

B) Pontos de melhoria no nivelamento: Em redes adequadamente fechadas e sem dependências externas, normalmente estas folgas podem significar uma oportunidade para se criar um cronograma melhorado (otimizado), onde a reorganização das atividades (sempre respeitando a lógica CPM e os recursos) eventualmente poderão reduzir o prazo final do projeto.

Para tal otimização, precisamos então entender que:

A) O Caminho Crítico Completo de um projeto pode conter folgas que não são processadas nem pelo CPM e nem pelo RCP;

B) Que as situações com folga em projetos calculados com o RCP são extremamente raras (impactos de dependências externas);

C) O projeto em questão, por não ter dependências externas, deve possuir uma solução otimizada na distribuição de atividades de tal forma com que se possa identificar um Caminho Crítico Completo de folga zero.

3 – Identificando o Caminho Crítico Completo com folga zero

Nivelamento de recursos é uma operação que não possui uma solução matemática – como é o caso do CPM; são necessárias iterações diversas dos softwares em “tentativa e erro” até encontrar uma solução melhorada para uma rede qualquer.

Utilizando então alternativas de nivelamento das atividades, para estas mesmas 16 atividades foi possível encontrar a seguinte solução:

3 - O Caminho Crítico Completo

3 – O Caminho Crítico Completo

É possível agora identificar um conjunto de atividades que de fato atendem as prerrogativas do Caminho Crítico do Projeto:

  • A) Determinam o Caminho Mais Longo;
  • B) Determinam a Data de Início do Projeto;
  • C) Determinam a Data de Término do Projeto;
  • D) Determinam a Menor Duração Possível do Projeto.

A solução otimizada para este cronograma – que antes era de 5 dias de duração – é de 4,5 dias.  Neste caso, a redução da duração total é de 10% e para identificar que existia esta possibilidade, foi necessário entendermos que nas soluções anteriores, uma ou mais condições acima não estavam sendo respeitadas.

4 – O Caminho Crítico Completo identificado no MS-Project

A partir do arquivo do MS-Project disponibilizado nesta postagem, se o usuário reorganizar as atividades conforme as recomendações descritas em laranja abaixo, será possível obter um cronograma final com o Caminho Crítico Completo e com a redução da duração total, sem conflito de horários para os recursos aplicados ao projeto.

4 - O Caminho Crítico Completo identificado no MS-Project

4 – O Caminho Crítico Completo identificado no MS-Project

Na ilustração:

  • Em azul: Atividade não-crítica (não pertence ao Caminho Crítico Completo)
  • Em laranja: Atividade crítica (pertence ao Caminho Crítico)
  • Em Cinza: Linha de Base (solução anterior)
  • Data Inicial: Conforme planejado, em 15/04/2014 as 09:00
  • Data Final: Otimizada em 0,5 dias, reduzindo de 21/04/2014 as 18:00 para 21:04/2014 as 9:00

Conclusões

Após calorosos debates em distintas listas e eventos, neste documento temos elementos de aplicação direta do entendimento do conceito de que o “Caminho Crítico Completo” é de fato uma ferramenta mais ampla e distinta do “Caminho Crítico” como tradicionalmente calculado pelo Método do Caminho Crítico (CPM).

Para verificarmos que folgas neste Caminho Crítico Completo podem eventualmente ser convertidos em uma melhoria do cronograma em termos de duração final, precisamos antes de mais nada reconhecer que existe um Caminho Crítico Completo que – independente de qualquer cálculo de folgas – deve ser iniciado no primeiro dia do projeto e deve ter uma sequência que garante o maior caminho do projeto, o seu menor prazo e a sua data final.

Assim, embora a máxima “O Caminho Crítico é o conjunto de atividades com folga zero” seja verdadeira para o CPM, não podemos nos contentar com “o Caminho Crítico Partido” (como ilustrado nas figuras 1 e 2) e devemos sempre identificar o conjunto de atividades que atende o Caminho Crítico Completo (clique no link para outra postagem relacionada!)

Baixe o arquivo MS-Project utilizado nesta postagem por este link: http://1drv.ms/1jqcexL – se não conseguir repetir a solução otimizada, escreva para mim para receber o MPP alterado conforme a ilustração (4) !!

Referências:

 http://pt.slideshare.net/petersmello/caminho-critico-por-recursos

– http://pt.slideshare.net/petersmello/corrente-crtica-abordagens-ccpm-e-sdpm

– http://pt.slideshare.net/petersmello/tcnicas-para-o-desenvolvimento-de-cronogramas


Escreva para petersmello@gmail.com

Desvio de Prazo através do Prazo Agregado


Em função dos e-mails recebidos relacionados aos exemplos da Curva-S versão 2.0, disponível neste link, esta postagem tem como principal objetivo fazer uma rápida introdução ao princípio de identificação do Desvio de Prazo, a partir dos conceitos da Análise do Prazo Agregado (www.earnedschedule.com).


 

Princípios do registro de Desvio de Prazo

O Desvio de Prazo é um indicador de apoio a Análise da Curva-S que calcula em dias o montante de trabalho que foi entregue deslocado no tempo.

Em outras palavras, não calcula a diferença entre o Avanço Planejado e o Avanço Realizado em um dado momento (que é a diferença para uma mesma data entre o Valor Planejado e o Valor Realizado), mas sim a diferença de prazo entre o momento de realização efetiva e o planejamento anterior.

As ilustrações a seguir descrevem o princípio do indicador.

1 – Uma Curva-S habitual, podendo representar HH, Peso, $, etc.

1 – Uma Curva-S habitual, podendo representar HH, Peso, $, etc.

1 – Uma Curva-S habitual, podendo representar HH, Peso, $, etc. (eixo x: número da semana)

 

2 – Análise desvios entre Planejado e Realizado em um dado momento histórico

Normalmente é registrado a diferença do resultado esperado (as entregas)

2 – Análise desvios entre Planejado e Realizado em um dado momento histórico

2 – Análise desvios entre Planejado e Realizado em um dado momento histórico (eixo x: período semanal, começando pelo dia do mês)

3 – Análise desvios entre Planejado e Realizado pelo Prazo Agregado

Para o Indicador de Desvio de Prazo*, o que se registra é a diferença histórica entre a data de entrega e a data planejada.

3 - Análise desvios entre Planejado e Realizado pelo Prazo Agregado

3 – Análise desvios entre Planejado e Realizado pelo Prazo Agregado (eixo x: número da semana no ano)

4 – Resultado da Aplicação para um projeto

Para detalhes dos itens apresentados neste exemplo, veja a postagem sobre a Curva-S, versão 2.0

4 - Análise de Desvios a partir da aplicação do Prazo Agregado

4 – Análise de Desvios a partir da aplicação do Prazo Agregado (eixo x: número da semana no ano)


 * Notas:

Pela terminologia do Earned Schedule – com base a tradução do material no Brasil – o “Desvio do Prazo Agregado” é similar a  Variação do Prazo Agregado. DP = -1 x VP (A razão para invertermos o sinal é para que a Curva-S com o desvio tenha um comportamento similar a da Curva-S do Planejado e Realizado)


Veja a Terminologia completa (contribuição de Paulo André) no seguinte link:

https://www.dropbox.com/s/ahtcwgp6ljwyq0f/Terminologia%20GVA%20e%20PA%20%28Eng-Port%29%20%281%29.pdf


Maiores informações: Baixe o livro Prazo Agregado, já traduzido em Português.

 

PA


 

SOFTWARE GRATUITO (Em testes, de meu desenvolvimento):

www.gestaodeprojetos.com.br/download/gratuito/DesvioDePrazo.zip

Software Gratuito para Cálculo do Desvio de Prazo

Software Gratuito para Cálculo do Desvio de Prazo


Escreva para petersmello@gmail.com

 

Vocês, Gerentes de Projetos, trabalham efetivamente com os Analistas de Negócios?

 Vocês, Gerentes de Projetos, trabalham efetivamente com os Analistas de Negócios? 

por ESI International

Não importa se o seu projeto é grande ou pequeno, mas como um Gerente de Projeto, você com certeza se encontrará em algum momento trabalhando com um Analista de Negócios.

Um Analista de Negócios na equipe do projeto vai ajudar você a entender como o projeto contribui para a empresa como um todo e vai garantir que você obtenha uma solução de alta qualidade, que trabalhe para alcançar os objetivos estratégicos e táticos. Que gerente de projeto não quer isso?

Trabalhar em direção de algo que realmente agregue valor ao negócio deve ser o objetivo de todo Gerente de Projeto, por isso, se algum Analista de Negócios lhe oferecer ajuda…aproveite! 

O papel de um Analista de Negócios pode variar de alguém que identifica os requisitos até alguém que contribui em nível estratégico sênior através de um portfolio de trabalho e que avalia soluções antes de elas se tornarem projetos, para garantir que a empresa invista de forma sensata.

Aqui estão algumas dicas para uma relação de trabalho eficaz: 

1 – Aprecie e concorde com o que o Analista de Negócios tem a oferecer: 

O Analista de Negócios e o Gerente de Projeto tem ambos os papéis claros para desempenhar em um projeto, agregando valor para ajudar a atingir a solução final de forma que atenda a todos os requisitos do cliente. No entanto, é muito importante que todos na equipe do projeto tenham ciência destes papéis e responsabilidades.

O Analista de Negócios tem um papel a desempenhar em todo o projeto, mas principalmente no início. Enquanto o Gerente de Projeto está passando pelo processo de iniciação do projeto, o Analista de Negócio pode trabalhar em paralelo para definir os requisitos.

O analista entende as circunstâncias dos negócios que levaram a este projeto que está sendo priorizado em primeiro lugar, e ele pode apoiar o projeto durante todo seu ciclo de vida. Ele também pode ser a voz do cliente, quando o cliente não está presente, e ajudar a traduzir as necessidades em um escopo do projeto que será entregue futuramente.

Há um outro momento chave em que a participação do Analista de Negócio torna ainda mais importante do que o normal: teste. O Analista de Negócio será capaz de controlar se os requisitos foram atingidos de forma adequada e aconselhar o cliente e a equipe do projeto durante a fase de testes.

Como todo analista é diferente, e cada organização espera coisas diferentes de suas equipes de analistas, você terá que definir papéis e responsabilidades com estes profissionais cada vez que tiver um projeto.

2 – Faça planejamento do trabalho do Analista de Negócio 

O cronograma do projeto é a principal ferramenta do Gerente de Projeto. Ele define exatamente o que será feito, quem o fará e o quanto as atividades mais longas vão demorar.

Se você estiver trabalhando com um Analista de Negócios , certifique-se de que você inclua todo o trabalho de Business Analysis em sua programação.

3 – Comunique-se regularmente 

Pode parecer que um Analista de Negócios e um Gerente de Projetos trabalham de maneiras completamente diferentes. Em alguns projetos pode até ser o caso, mas em projetos onde a relação deve ser mais efetiva deve-se trabalhar em parceria e comunicar regularmente.

Um Analista de Negócios deve comparecer em todas as reuniões da equipe do projeto uma vez que eles sempre têm algo relevante e valioso para dizer. Eles também podem se envolver nas reuniões de lições aprendidas e será provavelmente a pessoa no time mais próximo dos usuários de negócios e com a melhor compreensão de como o projeto irá afetá-los.

4 – Trabalhar em parceria nos riscos 

A gestão de riscos é frequentemente vista como um processo de gerenciamento de projeto fundamental, porque a falta de gerenciamento de riscos de forma adequada pode dificultar ou até mesmo impedir um projeto.

O Analista de Negócios também pode contribuir enormemente para as atividades de gestão de risco, porque ele vai ter uma grande compreensão do impacto do risco para o negócio e também será capaz de identificar riscos que talvez outras pessoas da equipe de projeto não identifiquem. Envolva-o na gestão de risco o mais cedo possível!

5 – Gerencie mudanças coletivamente 

O Analista de Negócios, estando perto dos usuários de negócios, pode ser de uma ajuda inestimável para o restante da equipe do projeto para compreender as mudanças que estão sendo levantadas, a lógica por trás delas, o impacto no projeto e na preparação de uma recomendação sobre se esta mudança deve ser ou não aceita. Se a mudança for aceita, o Analista de Negócio pode documentar os requisitos e ajudar o Gerente de Projeto entender o que precisa mudar na programação para acomodar os novos planos.

Os analistas são profissionais com grande capacidade de comunicação que podem apresentar ideias complexas de forma clara. Eles são excelentes solucionadores de problemas e podem analisar situações difíceis e por esta razão eles são um grande trunfo nas equipes de projeto, especialmente em ambientes onde a mudança constante é uma norma.

Agora pense em seus projetos e responda: você envolve o Analista de Negócios da sua empresa em seus projetos? Talvez seja hora de envolve-lo!

Fonte ESI INTERNATIONAL CENTRE OF EXCELLENCE 

A ESI INTERNATIONAL é líder global em soluções e treinamentos corporativos em Gestão de Projetos, Gestão Comportamental de Projetos, Gestão Ágil de Projetos, Gestão de Programa, Gestão de Contrato, Análise de Negócios e Habilidades de Negócios. 

www.esi-intl.com

www.esi-intl.com.br

A Curva-S, versão 2.0 (Indicadores de Planejado x Realizado)


Em função dos e-mails recebidos sobre o desenvolvimento das curvas a seguir, fiz uma introdução ao Desvio de Prazo Agregado em uma nova postagem.

Se a Análise do Prazo Agregado (www.earnedschedule.com) é ainda uma novidade para você, veja uma introdução neste link.


Os gráficos para acompanhamento de valores financeiros, percentuais de avanço em projetos, medições físicas de progresso  e tantas outras que fazem uma relação entre o “Planejado x Realizado” e trabalham com valores acumulados em projetos são comumente chamadas de “Curva-S” do projeto.

Nesta ilustração, temos uma Curva S genérica, que pode nos atender em uma avaliação do Previsto x Planejado de praticamente qualquer coisa (de materiais gastos, a valores pagos, entregas feitas, avanço físico, financeiro ou econômico de um projeto).

Curva S "genérica" (Planejado x Controle)

1 – Curva S “genérica” (Planejado x Controle)

O Objetivo desta postagem é o de apresentar uma aplicação de Prazo Agregado para o desenvolvimento de indicadores complementares à tradicional Curva-S, o que vamos chamar aqui de Curva-S versão 2.0.

A CURVA-S 2.0 - Análise de Desvios com o uso do Prazo Agregado

2 – A CURVA-S 2.0 – Análise de Desvios com o uso do Prazo Agregado

O DPA-d – Desvio do Prazo Agregado em Dias, acima ilustrado, foi identificado como uma solução para a avaliação de tendências de redução ou aumento da capacidade da equipe de projeto em realizar a sua entrega. Torna-se assim um instrumento visual de apoio à tomada de decisão para gestores de projeto.

Outros elementos derivados do uso da técnica oferecem também oportunidades inclusive para a projeção de resultados e serão apresentados em postagens posteriores.

Nesta primeira postagem, o destaque é a Análise de Desvios entre valores que foram planejados e sua realização.  Em muitos projetos em que participei como membro de equipe, gestor ou consultor, eu me deparei com a criação de um indicador de desvios a partir da subtração do valor acumulado planejado e o valor acumulado realizado.

Esta solução oferece uma análise de tendências razoável durante as primeiras fazes do projeto, mas o indicador “cai por terra” quando a realização do projeto ultrapassa o período original planejado.

A seguir, apresento uma aplicação inicial do Indicador de Desvio entre Planejamento e Realizado e a demonstração da “morte do indicador”; a partir daí, de forma similar, apresento a aplicação do Indicador de Desvio do Prazo Agregado em Dias (DPA-d) e uma demonstração de que o indicador permanece válido mesmo no instante em que o projeto ultrapassa o período originalmente planejado para a sua realização.

Parte 1 – Criando a  Curva-S tradicional

Os dados de origem para a criação da Curva-S podem representar Unidades, Peças, Reais, Dólares, Toneladas, Pessoas, Máquinas, etc, como a tabela abaixo.

Tabela com dados em qualquer unidade (Planejado x Realizado)

Tabela com dados em qualquer unidade (Planejado x Realizado)

Para facilitar a visualização, independente da unidade de origem, os valores da tabela acima são apresentados em percentuais. Os dados da tabela acima foram repassados à seguinte tabela, que é a base de nosso estudo.

Previsto x Realizado em %

Previsto x Realizado em %

Após a transformação dos dados de “unidades” para percentuais, a tabela acima também traz o “Desvio em Relação ao Previsto”.

  • O Desvio em Relação ao Previsto é a diferença entre o valor previsto (linha de base) e o valor realizado.
  • O Desvio em Relação ao Previsto Acumulado é a diferença entre o valor previsto acumulado e o valor realizado acumulado.

Parte 2 – A Curva-S com o Avanço do Período

Diversos relatórios com a Curva-S costumam apresentar o que já foi realizado tanto de forma acumulada (linha vermelha) como em seus valores por período (barras em azul)

Planejado x Realizado Acumulado + Dados de Avanço por Período

3 – Planejado x Realizado (Acumulado) e Dados de Avanço por Período

Esta apresentação parece nos auxiliar no entendimento de tendências pois é possível observar que o valor realizado aumenta ou reduz em cada período. No entanto, esta diferença pode ocorrer tanto por uma questão de alta/baixa produtividade ou em função dos valores originalmente previstos para o período em questão.

Na ilustração acima, a diminuição da produção entre as semanas 25/2 e 3/3 pode tanto ocorrer em função de um baixo desempenho como em função dos valores planejados (o peso de cada conjunto de atividades em relação a curva planejada).

A forma de termos “certeza” de que existe uma tendência de redução do produto realizado é a substituição dos valores realizados pela representação dos desvios acumulados, conforme a ilustração a seguir.

Planejado x Realizado (Acumulado) & Desvios Acumulados

4 – Planejado x Realizado (Acumulado) & Desvios Acumulados

Os dados em azul acima são calculados como a diferença entre o % acumulado realizado e o % acumulado planejado; os valores calculados foram multiplicados por “-1” de forma a obtermos uma apresentação no mesmo eixo.

Parte 3 – Melhoria da visibilidade do indicador

Os mesmos dados da tabela anterior são representados a seguir com duas alterações:

A) Transformação da representação do desvio para uma linha pontilhada, em substituição aos gráficos de barras;

B) Aumento da “escala” do desvio, colocando assim as três curvas em um mesmo “espaço visual”.  A Curva-S do Planejado e Realizado está dentro da faixa de 0% a 120% (escala à esquerda do gráfico) e a Curva-S do Desvio está dentro da faixa de 0% a 25% (escala à direita to gráfico).

Planejado x Realizado & Comparativo com Desvios (em outra escala)

5 – Planejado x Realizado & Comparativo com Desvios (em outra escala)

Agora, a linha de desvio parece não ilustrar muito sobre a tendência de melhoria ou piora dos resultados do projeto se comparado com a própria curva de valores realizados acumulados.

Em uma primeira análise, o indicador parece não nos dar nenhuma informação distinta do que já temos em relação a Curva-S Original.

A seguir, iremos apresentar o mesmo indicador em uma situação onde a produtividade em cada período vem sofrendo grande variação; esta variação é imediatamente “percebida” pelo indicador, embora não exista uma representação visível na Curva-S original.

Parte 4 – Aplicação do Indicador

Em projetos com grande variação entre valores previstos para o período e os valores realizados, o indicador de desvio torna-se um grande instrumento de análise do comportamento das equipes em cada etapa do projeto, conforme ilustrado a seguir.

Planejado x Realizado & Desvios

6 – Planejado x Realizado & Desvios

Temos finalmente um indicador de tendência que demonstra os picos de melhora ou piora de um projeto em relação a variação acumulada e com o progresso de cada período. Em uma primeira leitura, este desvio já parece ser o complemento desejado para a Curva-S versão 2.0.

Os dados utilizados para a ilustração acima são os descritos na tabela abaixo. O que podemos perceber é que embora o projeto esteja mantendo uma relativa aproximação entre o planejado e o acumulado, há saltos positivos e negativos nas produtividades de cada período, com reflexo imediato sobre a curva de desvios, que passam a ser um indicador importante não do resultado do projeto, mas da forma com que se está trabalhando para alcançá-lo.

Dados de Análise para a identificação de saltos de produtividade (maior e menor) em cada período.

7 – Dados de Análise para a identificação de saltos de produtividade (maior e menor) em cada período.

 

Parte 5 – “Morte do Indicador” – Situações onde os valores identificados já não tem representatividade no projeto.

“A Morte do Indicador” acontece quando o projeto ultrapassa o período inicialmente planejado. Neste instante, já não é mais possível avaliar a diferença entre Planejado e Realizado pois não há valores planejados.

Este é o mesmo fenômeno que nos impede de usar o Schedule Performance Index (Índice de Performance em Prazo) desenvolvido para a Análise de Valor Agregado: Este índice passa sempre a ser “1” quando o projeto ultrapassa a sua data prevista, deturpando os resultados esperados com a aplicação do indicador.

Em nosso projeto exemplo, se este estivesse previsto para ser realizado em 7 semanas ao invés das 10 semanas aqui representadas e a realização já estivesse na décima semana, o protótipo da Curva-S Versão 2.0 deixa de funcionar.

A morte do indicador após o fim do prazo previsto do projeto.

8 – A morte do indicador após o fim do prazo previsto do projeto.

Assim, quase identificamos um mecanismo simples de acompanhamento de projetos para complementar a Curva-S e dar aos gestores e equipe uma visão mais clara não só do resultado (a boca do jacaré abrindo ou não), mas a proporção do tamanho dos desvios e a direção da evolução do trabalho (melhorando ou piorando a cada semana).

Parte 6 – Indicador 2.0 – A substituição do Desvio entre “Planejado e Realizado” pelo Desvio de Prazo Agregado

O que fazer para corrigir este problema e criar uma nova perspectiva de acompanhamento de avanços em projeto?

A solução nós podemos obter com a integração desta característica visual de apresentação de desvios em uma Curva-S e a adoção do Cálculo do Prazo Agregado, uma técnica complementar ao Método do Valor Agregado (www.earnedschedule.com) que garante o “ajuste da Curva” em relação ao problema do índice não ter mais valor para projetos que já “venceram o seu prazo de validade”.

O gráfico abaixo é produzido a partir da coleta dos MESMOS DADOS disponíveis nos exemplos anteriores, o que permite que seja aplicado de “forma retroativa” a praticamente qualquer Curva-S já em uso na empresa. 

Análise de Desvios a partir da aplicação do Prazo Agregado

9 – Análise de Desvios a partir da aplicação do Prazo Agregado

O que temos neste caso é a aplicação da contagem de “desvios de prazo” a partir da definição do Prazo Agregado (em substituição ao Valor Agregado ou resultado registrado no projeto a cada semana).

O detalhamento de como devemos atuar em nossas tabelas para a Geração da Curva S para utilizarmos o Prazo Agregado é assunto para uma futura postagem, mas os resultados visíveis é o de conquistarmos o efeito desejado: A análise do Planejado x Realizado considerando o acompanhamento do registro dos desvios acumulados, permitindo assim uma análise de tendências e uma percepção do prejuízo acumulado.

Em resumo: Aplicamos o “Prazo Agregado” aos dados das tabelas utilizadas e plotamos o Desvio de Prazo Agregado em um eixo secundário do gráfico (o Desvio de Prazo Agregado está em “dias de projeto” e é uma unidade de Valor Agregado transformada em PRAZO).

O mesmo gráfico demonstrando apenas os gráficos em LINHAS (sem os dias acumulados em barras) é o seguinte:

Análise de Desvios com o uso do Prazo Agregado

10 – Análise de Desvios com o uso do Prazo Agregado

 

Aqui podemos examinar duas vantagens  em relação a aplicação do Desvio do Prazo Agregado  em substituição ao primeiro indicador apresentado (Diferença entre os dados de Planejamento e Controle)

1) O Prazo Agregado examina o avanço do projeto em função da comparação do Valor Agregado atual (o que se realizou, em qualquer unidade) com o momento histórico em que aquele valor estava previsto ocorrer. Assim, ele “não falha” na comparação de uma situação extrema onde o projeto já está muito meses atrasado em relação ao cronograma original.

A ilustração a seguir representa a avaliação dos mesmos dados que já se demonstraram FALHOS no gráfico “A morte do indicador após o fim do prazo previsto do projeto” . Neste caso, o Indicador de Desvios de Prazo Agregado é um SUCESSO.

O indicador com Desvios de Prazo Agregado não "morre" após o fim do período original previsto para o projeto.

11 – O indicador com Desvios de Prazo Agregado não “morre” após o fim do período original previsto para o projeto.

 

2) Outra vantagem é que o indicador se mostrou mais “sensível” na análise de ganhos ou prejuízos nos trabalhos em cada semana do que o indicador a partir dos desvios acumulados ilustrados no início desta postagem. Uma comparação entre os dois indicadores e a leitura dos dados reais “em campo” demonstra que o Desvio de Prazo Agregado tem maior grau de aderência ao comportamento entre cada período de medição do que o seu “antecessor”.

Em projetos "ainda no prazo" ambos os indicadores demonstram a tendência de aumento ou redução dos desvios de forma consistente com a Curva-S.

12 – Em projetos “ainda no prazo” ambos os indicadores demonstram a tendência de aumento ou redução dos desvios de forma consistente com a Curva-S, podendo atuarem como “substitutos” entre si.

Parte 7 – Publicação da Curva-S – Versão 2.0

A conclusão desta postagem é de que a Curva-S de qualquer conjunto de medições em projetos (Planejado x Realizado) pode se beneficiar de uma análise dos desvios acumulados, a fim de identificar a tendência de resolução ou piora dos desvios em questão e auxiliar a equipe de projeto a tomar ações de recuperação com uma oportunidade de avaliação de ganhos de melhoria mesmo quando ainda não recuperaram todo um prejuízo em um projeto.

No entanto, para adotar a visão de tendência de ganho ou prejuízo no avanço do projeto a cada medição, não podemos utilizar o simples registro da diferença entre o Planejado e o Realizado sob o risco de ter um “indicador morto” quando o projeto ultrapassa o período original previsto (sua Linha de Base). A solução ocorre – portanto – com a transformação da informação sobre o avanço do projeto (Valor Agregado) em uma análise de desvio do PRAZO AGREGADO (a partir das novidades aplicadas a Análise de Valor Agregado encontradas em www.earnedschedule.com)

A CURVA-S 2.0 - Análise de Desvios com o uso do Prazo Agregado

13 – A CURVA-S 2.0 – Análise de Desvios com o uso do Prazo Agregado

 

Em edições futuras (dependendo dos comentários recebidos nesta postagem!):

– COMO chegamos ao Prazo Agregado e

– COMO aplicá-lo de forma retroativa em planilhas que já possuem dados extraídos para as Curvas-S tradicionais.

 


 * Notas:

Pela terminologia do Earned Schedule – com base a tradução do material no Brasil –
o “Desvio do Prazo Agregado” é chamado de  Variação do Prazo Agregado.

Veja a Terminologia completa (contribuição de Paulo André) no seguinte link:

https://drive.google.com/file/d/0Bxk-BP_55YmIT19zQnF5TmM4XzZjTG91WDlPSi1sZXFMMDhr/edit

Maiores informações: Baixe o livro Prazo Agregado, já traduzido em Português.

 PA


Escreva para petersmello@gmail.com

 

 

Dicas para Aquisições em Projetos

No post anterior, apresentamos alguns aspectos importantes sobre contratos. O gerenciamento das aquisições em projetos envolve desafios maiores à medida que as organizações terceirizam cada vez mais suas atividades.

Em muitos dos projetos atuais, não se trata apenas de adquirir insumos e materiais. Estamos adquirindo uma nova gama de serviços, equipamentos de alta tecnologia, sistemas e subsistemas complexos para serem integrados ao nosso projeto. Coordenar o trabalho do projeto com o trabalho dos fornecedores pode ser uma tarefa árdua.

A integração com fornecedores pode abranger toda a cadeia de valor do produto em seu desenvolvimento. O contratante principal ou integrador de sistemas gerencia parcerias com empresas estendidas virtuais. É como se as empresas contratadas fizessem parte da equipe do projeto, uma equipe estendida do projeto, a fim de entregar de forma colaborativa um produto. A Embraer é um grande exemplo de integrador de sistemas, sendo o desenvolvimento dos jatos ERJ 170 / 190 um caso de sucesso.

embraer-cadeia

Figura 1 – Desenvolvimento dos jatos ERJ 170 / 190 e a cadeia produtiva da Embraer (BNDES, 2009)

O caso do Joint Strike Fighter reflete as grandes dificuldades em gerenciar contratos e parcerias (leia este artigo).

Screen Shot 2014-03-24 at 15.28.39

Figura 2 – Histórico de desenvolvimento do F-35

Aqui vão algumas dicas para aquisições em projetos:

  • Gerenciar relacionamentos é extremamente importante: manter boas relações com os fornecedores é vital para o êxito de qualquer projeto. Havendo disputas entre contratante e contratado, os riscos de fracasso do projeto aumentam significativamente.

Lembre-se que o objetivo das aquisições é receber aquilo que você necessita para a realização do seu projeto (materiais, equipamentos, serviços etc). Quando o fornecedor não entrega o combinado, por mais que existam multas e outras penalidades contratuais, o projeto será prejudicado.

  • Aprovações podem ser demoradas: costuma-se dizer que as aprovações levam o dobro (ou mais) do tempo que planejamos. Portanto, planeje-se para eventuais atrasos nos processos de aquisições (licitações e outras modalidades de compra, por exemplo).

Procure conduzir as aquisições o quanto antes. Aprovações, solicitações, contato com fornecedores, análises das propostas podem exigir um tempo maior do que o esperado.

  • Os fornecedores precisam ter lucro: parece óbvio, mas às vezes esquecemos disso. Não há incentivo para os fornecedores se eles não tiverem lucro ou se o lucro for pequeno e o risco muito alto. Eu já vi organizações adquirindo produtos / serviços por preços claramente inferiores aos valores reais praticados. O resultado disso é que o fornecedor pode entregar algo de pior qualidade ou mesmo não ser capaz de entregar coisa alguma.

Nunca é demais lembrar que o objetivo das aquisições é receber o produto / serviço que necessitamos, com a qualidade e requisitos desejados, no tempo certo e por um preço razoável. Não pense que é injusto o seu fornecedor ter 100% de lucro, pense no custo/benefício para o seu projeto. Pode valer a pena pagar mais caro por um bom produto / serviço.

  • Utilize opinião especializada: trata-se de uma técnica que aparece em vários processos do Guia PMBOK®. Mas é pouco utilizada. A sua organização deve possuir procedimentos para aquisições, um departamento responsável por compras e um setor de assessoria jurídica. Busque ajuda e orientação.

 

  • Cláusulas contratuais: você leu o contrato? Muitos gerentes descobrem tardiamente que o contrato não atende a suas expectativas. Também é importante se familiarizar com termos e condições padrão.

O contrato é um vínculo jurídico resultante de um acordo comum entre as partes, criando obrigações e direitos. No contrato, está definido o que você pode cobrar do fornecedor, a modo de acompanhar e receber serviços / produtos, bem como as suas obrigações para com o fornecedor (pagamentos, por exemplo). Se você não entendeu alguma cláusula contratual, busque opinião especializada!

  • Condições de pagamento: os diferentes tipos de contrato discutidos nos posts anteriores trazem também implicações quanto às condições de pagamento. Definir as aprovações e aceitações necessárias para realizar os pagamentos, bem como o calendário de pagamento é essencial para o gerenciamento dos custos do projeto, seu orçamento e fluxo de caixa.

Podemos negociar um desconto à vista? Devemos pagar após receber o serviço? Vamos parcelar o pagamento dos produtos? Precisamos responder a essas e outras perguntas antes de definir as condições de pagamento. Lembre-se que que as condições de pagamento estabelecem obrigações para você, contratante!

  • Não é apenas assinar o contrato: os processos de aquisições não terminam quando o contrato for assinado. O sucesso das aquisições envolve acompanhar e gerenciar os contratos, garantindo a entrega dos resultados esperados. As aquisições terminam após recebermos devidamente os produtos / serviços adquiridos e encerrarmos os contratos, cumprindo com as obrigações de ambas as partes.

 

Para aqueles que desejarem se aprofundar em contratos de parceria / integradores de sistemas, vale a pena ler esta dissertação: Enterprise Integration Strategies Across Virtual Extended Enterprise Networks (MIT, 2006).

Na próxima semana, discutiremos análises quantitativas de riscos e simulações, bem como o uso de softwares como @Risk e Primavera Risk Analysis. Não percam!

Cronogramas dinâmicos em Ágil

Graças a postagem do Fábio Cruz, que fez uma excelente apresentação sobre Cronogramas Ágeis no Blog da MundoPM,  eu posso adiantar a publicação de um assunto que há tempos quero apresentar neste espaço: O Agendamento Dinâmico de Recursos para métodos Ágeis.

Para avançar com este tema, que exige uma introdução aos cronogramas convencionais e também as formas de se desenvolver cronogramas no mundo Ágil, vou contar com os exemplos do artigo do Fábio e a partir deles incrementar uma aplicação de outros conceitos em cronogramas para criarmos então “Cronogramas dinâmicos” para métodos Ágeis.

Parte 1: Introdução –

Parte 2:  Cronogramas dinâmicos a partir do Agendamento Dinâmico de Recursos (Dynamic Resource Scheduling)

Um agendamento dinâmico é baseado no aproveitamento de recursos computacionais e o detalhamento de cronogramas sem a necessidade de se manter centenas de relacionamentos entre atividades intermediárias.  Para os puristas da aplicação do Método do Caminho Crítico seria uma heresia, pois estamos falando sobre a manutenção de cronogramas sem a manutenção de relacionamentos lógicos (dependências entre atividades). Cronogramas são então desenvolvidos a partir da distribuição de cargas de trabalho entre recursos, utilizando algoritmos de nivelamento de recursos.

Qual o benefício?

Em métodos ágeis, nós vamos substituir a necessidade de desenvolver um longo cronograma para a identificação de datas de entrega por um método que já estabelece “datas fixas” para conjuntos de entrega e depois determina os elementos que compõe cada um destes conjuntos. Abaixo me utilizo de uma ilustração da postagem do Fábio Cruz:

2No entanto, a definição do que pode caber em cada um destas etapas de entrega (os Sprints) requer uma avaliação do conjunto de estorias necessárias, os recursos disponíveis, as prioridades e valor para o negócio de cada subconjunto de entregas. Este é um trabalho que – se bem elaborado – irá agregar valor ao produto rapidamente, já nas primeiras entregas e também vai estabelecer uma prioridade para componentes fundamentais do projeto que servirão para entregas futuras do projeto.

Em outras palavras, com uma equipe de 4 pessoas trabalhando 4 semanas eu tenho 640 horas de trabalho. Estas horas devem ser empregadas no desenvolvimento de estorias e na correção de bugs.  Mas quais estórias?

A seleção de estórias para cada conjunto de entregas ou para um “Sprint” devem atender um critério de utilidade (valor do negócio) para o cliente; no entanto, não basta apenas selecionar os itens classificados com a maior pontuação para o negócio , pois se não desenvolvermos uma relação lógica também entre as entregas, etapas futuras do projeto poderão ter uma produtividade reduzida.

O Agendamento Dinâmico de Recursos irá permitir uma rápida avaliação de “quantidades de trabalho” e prioridades para então auxiliar a equipe a decidir quais são os elementos que serão colocados em cada entrega.

Parte 3 – Exemplo Prático

A ordem dos tratores altera a construção da ponte.
Em muitos casos, a priorização adequada entre duas tarefas em uma estória pode favorecer a liberação da equipe para trabalhar em mais itens em um mesmo período.

2014-05-04 12_29_34-3.png (877×625)

Figura parcial retirada da postagem de Fábio Cruz, sobre Cronogramas Ágeis

Vamos imaginar 4 tarefas: 1.Ap, 1.Bp,1.At, 1.Bt – todas elas necessárias para cumprirmos com a “Estoria 1”.

  • 1.Ap e 1.Bp são atividades de programação e serão realizadas por Fábio Cruz, em 8 horas e 4 horas respectivamente.
  • 1.At e 1.Bt são atividades de testes e serão realizadas por Peter Mello, em 8 horas cada.
  • Há uma dependência lógica entre cada item de programação e seu respectivo teste.
  • O trabalho total previsto é de 28 horas (12 horas de programação do Fábio e 16 horas de testes do Peter).

Em um cronograma inicial Ágil, conforme exemplo do Fábio Cruz, teríamos algo como:

Projeto completo, com base ao exemplo de Fábio Cruz

Projeto completo, com base ao exemplo de Fábio Cruz

 Neste caso, a equipe estabelece o detalhamento da sequência entre as atividades durante as reuniões diárias e o “micro-planejamento” está sob controle integral da equipe. As tarefas em questão sequer aparecem no cronograma pois estão “contidas” na Estoria 1.

Ao adotarmos o Agendamento Dinâmico, a primeira grande alteração em nosso cronograma é que para cada Atividade nós iremos armazenar informações mais específicas sobre a carga de trabalho esperada e o “valor para o negócio” que é um mecanismo para se priorizar atividades e entregas em função do benefício que será dado ao usuário final.  Isso não é realmente um trabalho extra tendo em vista que estas estimativas também são necessárias para a própria definição do que é que “cabe” em uma entrega e sua priorização (muitas equipes ágeis usam ferramentas na WEB ou Excel para esta classificação).

Se utilizarmos o MS-Project, a “carga de trabalho” será aplicada no campo de  duração da atividade e o “Valor do Negócio” será aplicado no campo de “Prioridade”.  Também iremos dar o nome do recurso para cada atividade e – em alguns casos – criar alguns relacionamentos lógicos.

Precisamos então ampliar o detalhe de nosso cronograma, para algo parecido com:

Tarefas: Carga & Recurso

Tarefas: Carga & Recurso

Este cronograma já é “assustador” para muitas equipes de projetos ágeis pois aparenta possuir um nível de controle que não gera benefícios à equipe pois ela é responsável pelo seu micro-planejamento. No entanto, A definição de cargas de trabalho por tarefa já é uma necessidade compreendida por estas equipes pois é através desta análise de carga que podemos verificar qual volume de trabalho realmente por ser entregue para cada estoria, iteração ou entrega.

Ao utilizarmos os recursos de nivelamento da ferramenta, nós temos então um cronograma resultante que servirá – no mínimo – para verificarmos se a quantidade de trabalho prevista para uma iteração é compatível com o tamanho da equipe. No exemplo abaixo, além do Fábio e Peter, a primeira Iteração teve o seu trabalho total distribuído também com a Ana e o José.

Tarefas: Distribuição por Carga e Recursos

Tarefas: Distribuição por Carga e Recursos

O nivelamento neste caso demonstra que o tempo previsto para a Iteração 1 (9 dias) é possível de ser realizado: A soma de toda a carga de trabalho prevista é compatível com a disponibilidade de horas da equipe.

Isso normalmente é feito no Excel ou a partir da sensibilidade da equipe, mas pode conter “vícios”  que impedem que o tempo total do projeto seja otimizado. Quando o tempo total é otimizado, temos maior disponibilidade para a realização de novas tarefas, estórias ou bug-fixes em uma mesma iteração.

Cronogramas dinâmicos podem nos apresentar oportunidades maravilhosas, cuja continuidade na sua aplicação irá permitir que a equipe descubra caminhos alternativos para a realização do trabalho.

No exemplo a seguir, a simples troca na ordem de execução das tarefas 1.A e 1.B permitem que a Estória 1 seja concluída em 2,5 dias no lugar de 3. Quando isso se repete em diversas outras estorias e iterações, equipes podem produzir resultados em casos já verificados entre 5% a 20% de redução no tempo para a realização de um mesmo trabalho.

Otimização de Resultados

Otimização de Resultados
(inversão da ordem de início entre a atividade 1.Ap e 1.Bp em relação ao cronograma anterior)

É muito comum equipes auto-gerenciadas perceberem pequenos ganhos locais com a inversão de certas prioridades entre atividades, completando assim um mesmo trabalho em uma duração menor (embora o trabalho permaneça o mesmo).

No entanto, uma administração dinâmica destes nivelamentos, sendo continuamente repetidos de tempos em tempos (em uma reunião semanal, por exemplo), podem garantir as equipes a identificação de tempos extras para a realização de bug-fixes necessários ou excepcionalmente até para a inclusão de estórias ainda não previstas em uma iteração.

A adoção de Cronogramas dinâmicos em Ágil, com maior detalhe no nível das tarefas, não significa abrir mão do auto-gerenciamento das equipes e sim a tomada de decisão de forma “mais científica ou matemática” em relação ao trabalho que deve ser realizado no dia-a-dia.  Um cronograma construído com alguns links principais e sempre utilizando a definição de “carga de trabalho” no lugar de “duração”, bem como o nivelamento de recursos pode se tornar um instrumento valioso para que a própria equipe tome decisões importantes em relação a continuidade do seu trabalho, além de permitir argumentos consistentes na hora de negociar com o “Scrum Master” ou “Product Owner” quais são os elementos que necessariamente devem entrar em uma iteração.

Parte 4 – Resumo

O Agendamento Dinâmico deve permitir:

1) Decisão rápida em relação ao que está no “backlog” ou lista de funções do sistema e a sua distribuição nas entregas (os “Sprints” no caso do Scrum);

– Para cada estória ou conjunto de tarefas, deve auxiliar a equipe na tomada de decisão em relação a distribuição no tempo, permitindo a identificação de conjuntos lógicos e sua respectiva carga de trabalho e valor do negócio para cada entrega.

2) Organização do trabalho para cada dia, semana ou período, favorecendo um sequenciamento lógico para atender uma entrega.

3) Ganhos de produtividade com a absorção de 5% a 20% de tarefas extras por iteração, simplesmente com a otimização da sequência lógica entre eles;

4) Manutenção de cronogramas com um grau de dificuldade muitas vezes inferior a adoção de um detalhamento com base ao Método do Caminho Crítico, visto que somente as dependências obrigatórias (programação > testes) precisam ser definidas e o restante do cronograma é desenvolvido a partir dos recursos de nivelamento presentes em diversas ferramentas.

Parte 5 – Agendamento Dinâmico Avançado

Para as equipes que vencerem o medo em relação ao desenvolvimento de cronogramas com um nível de detalhe maior do que o normalmente empregado em projetos ágeis, vale verificar as vantagens de se utilizar ferramentas que realizam o nivelamento de recursos baseado em habilidades, como é o caso do Spider Project e do Primavera.  Estas ferramentas poderão auxiliar a equipe a decidir qual programador ou testador deve ser utilizado em atividades similares, garantindo assim um resultado global na distribuição de tarefas mais uniforme, mais rápido e com redução de durações significativas em um projeto.

Métodos Ágeis quebraram paradigmas de Gestão para alcançarem resultados melhorados em relação ao emprego de técnicas tradicionais. Por que não quebrar mais um paradigma e desenvolver cronogramas dinâmicos?  Acredite: A ordem dos tratores altera a construção da ponte!

Escreva para petersmello@gmail.com

Aquisições em Projetos: Contratos

O gerenciamento das aquisições, que já foi assunto de um post anterior, é uma área que vem ganhando bastante importância, especialmente em grandes projetos. As pressões de outsourcing combinadas às necessidades de integrar e coordenar parcerios, fornecedores e demais stakeholders, tornam ainda mais complexo o gerenciamento das aquisições.

Entretanto, muitos profissionais ainda tem dúvidas quanto aos tipos de contratos, bem como quais cláusulas devem ou não ser incluídas. Antes de avançar no assunto, cumpre estabelecer o que é um contrato:

Contrato é um vínculo jurídico estabelecido a partir de um acordo de vontades que impõe

obrigações mútuas para as partes envolvidas.

Sendo um acordo de vontades, os envolvidos podem definir livremente objeto, obrigações e cláusulas, desde que não haja ilegalidade. Isto é, tudo o que não está proibido por lei é permitido. É aqui que entram as grandes dificuldades no gerenciamento das aquisições, uma vez que podemos definir diferentes aspectos do contrato.

Algum tempo atrás, um gerente de projetos procurou-me para apresentar uma situação que ele estava enfrentando em determinado contrato. Perguntou-me o que seria correto em relação a questão apresentada. Eu o aconselhei a tentar um acordo, uma vez que a questão não estava definida em contrato. Caso contrário, a solução poderia envolver uma longa e cara demanda judicial…

Contrato é um acordo de vontades livremente firmado entre as partes,
para criar obrigações e direitos recíprocos dentro da lei.
As partes envolvidas possuem obrigações e direitos. Suponha um simples contrato de compra e venda. É essencial definir o objeto, seu valor, quando ele será entregue e quando será pago. Outros aspectos podem ser endereçados no contrato, prevendo a possibilidade de mudanças, quebra contratual etc.
O comprador tem o direito de receber o objeto e o dever de pagar por ele. Já o vendedor tem o direito de receber o dinheiro e a obrigação de entregar o objeto.
Mas as aquisições em projetos não costumam ser tão simples. Precisamos especificar responsabilidades e atribuições, cláusulas de garantia, treinamento, manuais e documentação, operação assistida, incentivos e penalidades relacionadas ao escopo, tempo e custo,gerenciamento de mudanças, bem como outras áreas importantes.
Existem basicamente três tipos de contratos, conforme definidos a seguir (Trentim, 2010).
Contratos de PREÇO FIXO: preço fixo total para determinado produto ou serviço a ser fornecido, podendo incorporar incentivos e penalidades. Nos contratos de preço fixo, os compradores devem especificar detalhadaente os produtos ou serviços a seremadquiridos, uma vez que mudanças de escopo acarretam aumentos no preço do contrato.
  • Contratos de Preço Fixo Garantido (PFG)
  • Contrato de Preço Fixo com Remuneração de Incentivo (PFRI)
  • Contratos de Preço Fixo com Ajuste Econômico do Preço (PFAEP)

Contratos de CUSTOS REEMBOLSÁVEIS: envolve o reembolsos dos custos incorridos, acrescidos de uma remuneração que corresponde ao lucro do fornecedor. Também podem incluir cláusulas de incentivos e penalidades. É uma modalidade de contratação mais flexível, não exigindo a definição detalhada de todo o escopo do produto ou serviço contratado.

  • Contratos de Custo mais Remuneração Fixa (CMRF)
  • Contratos de Custo mais Remuneração de Incentivo (CMRF)
  • Contratos de Custo mais Remuneração Concedida (CMRC)

Contratos de TEMPO E MATERIAL: tipo de contrato híbrido que contêm aspectos tanto de contratos de custos reembolsáveis quanto de contratos de preço fixo, geralmente utilizados para aquisições menores. Neste tipo de contrato, o fornecedor oferece uma cotação de seus produtos e serviços, enquanto o comprador pode adquiri-los na medida de sua necessidade.

Para saber mais sobre contratos, leia este .PDF e visite este link. Também vale conferir o livro Project Procurement Management, Quentin Flemig. Na próxima semana, veremos dicas para o gerenciamento das aquisições. Como planejar as aquisições? Como conduzir e controlar as aquisições? Até lá!

jpeg