Simulando Hipóteses em um Cronograma (aplicação de Premissas)

Se você quiser ser notificado dos próximos artigos, cadastre seu e-mail aqui ao lado, em Assine o Blogtek! SEU E-MAIL NÃO SERÁ USADO POR TERCEIROS.

---

Aplicando premissas em um cronograma

Conforme o Practice Standard of Scheduling (PMI, 2a edição) e o PMBOK (PMI,, 5a edição), o desenvolvimento de cronogramas de projeto representa uma atividade de “modelagem” (Schedule Modeling) onde estabelecemos um relacionamento entre a EAP aplicada (Estrutura Analítica do Projeto, onde definimos as principais entregas/fases ou entregas de um projeto) e as atividades que irão compor o cronograma.

As atividades deste “schedule model” se utiliza não somente do uso de conceitos tradicionais, como o CPM (Critical Path Method – Método do Caminho Crítico) e GVA (Gerenciamento por Valor Agregado), mas também de alguns elementos complementares, menos comuns e de grande aplicação em modelos mais elaborados:

A) Análise de recursos com aplicação em atividades baseado em índice de produtividade;

B) Rede lógica condicional, representada por um conjunto de atividades que poderão ou não acontecer a partir da definição de uma premissa;

C) Inclusão de recursos no projeto baseado nas premissas escolhidas.

O cronograma é montado a partir de um conjunto de hipóteses que são aplicadas no cronograma.

Os passos executados foram:

1. Definição de um cenário – análise da situação desejada para o projeto, com a premissa de se aplicar um “Desenvolvedor Sênior” em um caminho e a criação de um caminho alternativo com o uso de um “Desenvolvedor pleno.
2. Aplicação de Restrições de Custo e Prazo – atribuição de limites necessários ao projeto.
3. Avaliação necessária – conjunto de questões a serem resolvidas pela criação do modelo.
4. Modelo do Cronograma Condicional – criação da rede lógica com condicionais.
5. Definição de durações baseada em produtividade – Aplicação das estimativas por tipo de desenvolvedor.
6. Produção de recursos – mecanismo para definir “ou” um profissional sênior “ou” um profissional pleno.
7. Análise de Custos e Prazos – execução dos cenários para cada uma das hipóteses.
8. Resultados – Análise gráfica e numérica dos resultados obtidos.

1.  Cenário

Uma empresa tem um serviço a ser realizado para um cliente e tem em sua base de talentos o registro de um Desenvolvedor Sênior e um Desenvolvedor Pleno. Ambos podem iniciar suas atividades com dois dias de serem chamados a participar do projeto.

Com base a experiências anteriores, a empresa tem como premissa que o Desenvolvedor Sênior tem a capacidade de desenvolver o trabalho com uma velocidade média de 1,5 x quando comparado com o Desenvolvedor Pleno. Considera-se dias corridos e um trabalho diário de 10 horas.

O trabalho total considerado é de 500 unidades, que poderão ser executadas em velocidades diferentes em função da produtividade de cada desenvolvedor.

• Estima-se que o Desenvolvedor Pleno realize 1 unidade por hora.
• Estima-se que o Desenvolvedor Pleno realize 1,5 unidades por hora.
• O Programador Sênior custa R$ 35,00 por hora
• O Programador Pleno custa R$ 20,00.

2. Restrições de custo e prazo:

– O Projeto não pode custar mais de R$ 12.000,00;

– O Projeto não pode levar mais de 45 dias;

3. Avaliação necessária:

– O projeto custa mais caro quando realizado com o Desenvolvedor Sênior ou Pleno?

– Qual deve ser a opção escolhida pela empresa?

4. Modelo do Cronograma Condicional:

Um modelo lógico com condicionais necessita de um tipo de atividade especial chamado “switch”. O “switch” contém uma “chave de decisão” e permite que o projeto continue por distintas redes.

Na ilustração é possível ver duas possíveis redes definidas a partir do “switch” (clique na imagem para ampliar).

• A atividade com ID 1 (Decidir por Programador Sênior) é uma atividade condicional (Switch) e as duas atividades a seguir estão configuradas para responder em caso de “SIM” (ID 2 – Contratar Programador Sênior) ou de “NÃO” (ID 3 – Contratar Programador Pleno);

• O caminho padrão selecionado corresponde ao caminho “SIM”, sinalizado com as bordas em vermelho para as atividades ID-1 > ID-2 > ID-4 > ID-6;

• O outro caminho corresponde a opção “NÃO”, com as atividades ID-1 > ID-3 > ID-5 > ID-6.

5. Definição de durações baseado em produtividade:

O trabalho previsto para o projeto foi definido a partir da aplicação de um volume com 500 unidades de trabalho a serem realizadas (Atividade com ID 6 – Desenvolver a Aplicação). Para a mesma atividade, são introduzidas duas possibilidades: A aplicação de um “programador pleno” com uma produtividade de 1 unidade para cada hora de trabalho e um “programador sênior” com uma produtividade de 1,5 unidades para cada hora de trabalho.

 

 

6. Produção de Recursos:

O uso da função do aplicativo de “Produção de recurso” faz com que seja possível iniciar o projeto com nenhuma unidade de programadores (plenos ou sênior) e então – a partir da seleção do condicional (SIM ou NÃO) produzir um recurso do tipo escolhido pelo usuário.

A) Se o usuário selecionar como premissa “SIM, vamos contratar um programador sênior”, a atividade ID-4 (chegada do Programador Sênior) irá configurar o aplicativo para ter 1 unidade do recurso desejado (O Gantt irá mostrar as outras atividades em coloração branca, quase invisível).

 

B) Se o usuário escolher a outra opção, 1 unidade do recurso “programador pleno” será o resultado da atividade ID-5 (o Gantt irá mostrar a contratação do Sênior em coloração branca).

 

7. Análise de prazo e custo

Cenário Condicional 1 – Aplicação do Programador Sênior.

O resultado calculado para o cronograma, partindo da premissa de que o Programador Sênior será contratado é:

1. Prazo total : 35 dias
2. Custo com o programador : R$ 11.666,67 (500 unidades / 1,5 unidades por hora * R$ 35,00)

(** Clique para expandir a imagem **)

Cenário Condicional 2 – Aplicação do Programador Pleno

O resultado calculado para o cronograma, partindo da premissa de que o Programador Pleno será contratado é:

1. Prazo total : 52 dias
2. Custo com o programador : R$ 10.000 (500 unidades a R$ 20,00 cada)

(** Clique para expandir a imagem **)

8. Resultados

Avaliação gráfica: Curva de Análise de Valor Agregado para esforço (horas de trabalho)

• A linha em Azul demonstra que o recurso pleno leva 500 horas para realizar 500 unidades.
• A linha em Vermelho demonstra que o recurso sênior leva 333 horas para realizar as mesmas 500 unidades.

Avaliação gráfica: Curva de Análise de Valor Agregado para custos.

• A linha verde identifica o consumo de R$ 11.66,67 em 35 dias (linha de base do projeto);
• A linha vermelha identifica o valor da linha de base deslocado em função do atraso com o programador sênior (denotando 7 uma diferença total de 17 dias úteis);
• A linha em azul denota que a realização do projeto com o uso do recurso Pleno cumpriria os objetivos em 52 dias, com um custo de R$ 10.000,00.

Conclusões

• Ambos cenários cumprem com a restrição financeira (projeto restrito a um custo máximo de R$ 12.000,00), logo são viáveis.
• O cenário com o programador pleno, embora represente uma economia de R$ 1.666,67 em relação ao uso do programador sênior, não cumpre com a restrição de prazo (restrição de prazo máximo: 45 dias). Desta forma, a empresa deve realizar a entrega em 35 dias, o que deverá encantar o cliente  (16.6% mais caro, porém 67% mais rápido em relação ao outro cenário).

 

---

 

Estaremos sempre abordando em detalhes aspectos de Liderança e Gestão, Gerenciamento de Projetos, Gestão da Manutenção nos próximos artigos do Blogtek. Para manter-se informado sobre os próximos artigos, cadastre seu e-mail em Assine o Blogtek! SEU E-MAIL NÃO SERÁ USADO POR TERCEIROS.

Incoming search terms:

• Aplicação de cronograma
• como simular uma hipóteses
• Forum de gest?o de projetos
• Peter Mello gerenciamento projetos
• premissas do cronograma

Clique aqui e cadastre-se para receber uma notificação por email sempre que um novo artigo for postado

Seu email não será utilizado por terceiros nem para envio de spam.