Solucionar Problemas de Qualidade

 

Os problemas de qualidade podem não ser incrementados até ao nível de uma questão mas não deixam de ser problemas e devem ser solucionados utilizando as mesmas técnicas de solução de problemas do projecto. Adivinhar a causa do problema é um método que raras vezes funciona. Uma abordagem estruturada é muito mais efectiva. Queremos não só resolver este problema particular, mas também queremos compreender o problema de forma suficiente a que possamos identificar a causa que se encontra na sua raiz e garantir que este problema de qualidade particular não ocorra outra vez.

Utilize o seguinte processo geral para identificar e solucionar problemas de qualidade.

1. Identificar o problema ou sintoma. Não deve assumir que todos conhecem já o problema. Encontrar tempo para documentar o problema em termos claros que todos possam compreender. Garanta, também, que explica o impacto no projecto do problema de qualidade.
2. Identificar a raiz causal. Este é o passo mais importante, já que não queremos perder o nosso tempo resolvendo um sintoma de qualidade. Pelo contrário, devemos ser muito claros na raiz causal e explicar como esta causa causa em úlima instância o problema. Se não conseguimos determinar a raiz causal do problema apercebido isso significa que não investigámos tão profundamente quanto necessário.
3. Determinar alternativas e impactos. O gestor do projecto pode atribuir uma ou mais pessoas para determinar as alternativas. Para cada alternativa, devem também destacar o impacto no projecto.
4. Seleccionar a melhor alternativa. A equipa do projecto, o sponsor e o cliente podem ainda ser envolvidos na determinação da melhor alternativa. Contudo, a equipa de projecto pode ser capaz de resolver por si própria o problema se este não constituir uma questão formal. De facto, pode ser um problema relacionado com os produtos de trabalho intermédios que se encontram integralmente sob o controlo da equipa de projecto.
5. Executar. Um mini-plano deve ser activado para enfrentar o problema de qualidade e implementar a alternative escolhida. Estas actividades devem ser movidas para o plano de trabalho do projecto de forma a garantir que são realizadas.
6. Validar. Este processo deve ser revalidado para garantir que a qualidade foi melhorada conforme o esperado. Se a qualidade melhorou ou está a caminha nesse sentido, pode monitorar a partir daì. Contudo, se a qualidade não está a melhorar conforme esperado devem ser adoptadas acções correctivas se necessário.

"Causas Especiais” e "Causas Comuns" de Erros

Quando se procuram as causas de defeitos de produtos (erros) verificamos que elas caem em duas categorias gerais. O Dr Edward Deming chama a estes erros "causa especial" e "causa comum".

As "causas especiais" são aquelas que os utilizadores locais do produto podem encontrar e, por vezes, solucionar. Isto inclui deficiências, falta de formação, uso deficiente de equipamento, vandalismo, etc.

A segunda categoria é denominada "causas comuns". Estas causas podem provocar variações grandes na qualidade e incluem problemas sistemáticos que os utilizadores não podem determinar. Por exemplo, erros de causa comum podem incluir imperfeições menores no equipamento, desenho deficiente do produto, má performance do equipamento, processos que trabalham mas não estão optimizados, etc. Estes problemas são "comuns”, mas são muito difíceis de detectar pelos utilizadores locais.  

As desvantagens do Percent Complete

 

ou O Acompanhamento e Controlo do Projecto em MS Project

Quando um gestor de projecto chega à ocasião em que se torna necessário recolher o real progresso há uma tendência para actualizar a informação colocando um valor no campo Percent Complete (% complete) para as actividades. Isto acontece por duas razões:

– As empresas podem considerar difícil obter dados referentes ao trabalho real dos membros da equipa.

– Também a barra standard de tracking do programa baseia-se neste método e assim esta parece ser a escolha mais lógica.

Apesar deste procedimento parecer o mais fácil, quer do ponto de vista da obtenção de informação dos vários membros da equipa e a quantidade de tempo que é necessária para actualizar o plano, há desvantagens na perspectiva de se obter um exacto calendário de execução do projecto. Quando se acompanha o progresso com a introdução de Percent Complete o Project pode mudar os valores nos campos de Work. E certamente não é isso que é pretendido se o projecto foi aprovado com base numa determinada quantidade esforço de trabalho.

Como Percent Complete afecta o calendário restante

Quando se actualiza o Percent Complete da actividade, o Project multiplica o campo de Duração da Actividade (Task Duration) pela percentagem introduzida e introduz esse valor como a duração real (Actual Duration). De seguida marca tantos períodos de tempo desde o início da actividade como estando concluídos, utilizando as atribuições das alocações planeadas durantes aqueles períodos de tempo. O trabalho planeado nesses períodos de tempo fica agora marcado como trabalho real concluído (actual work completed).

O Project assume que o trabalho se desenrolou conforme planeado e isto pode muitas vezes ser irrealista.

Assim, se pretende introduzir o tracking com o Percent Complete e pretendemos que o Project reflicta com precisão o progresso planeado, deve então mudar o Work e as Units da alocação do recurso conforme a execução real antes de introduzir a percentagem

E se houver recursos múltiplos numa actividade?

Outra desvantagem de introduzir os dados como Percent Complete é que este campo existe ao nível da actividade e não ao nível da alocação do recurso (resource assignment level).

Quando entramos uma percentagem, o Project assume que todos os recursos estão a progredir com o mesmo ritmo. Isto pode não ser verdade, especialmente nas instâncias em que os recursos possuem diferentes responsabilidades. Se um recurso concluiu 75% da sua atribuição e outro somente 25%, seria mais acertado introduzir Percent Work Complete (Campo:  %Work Complete) , para cada um dos recursos alocados. Desta forma o Project vai calcular o Percent Complete ao nível da actividade no seu todo mas não se evitaram os outros problemas acima referidos. O trabalho completado continua a ser registado como tendo sido desenvolvidos nos dias para os quais se encontrava originalmente planeado.

 

E o trabalho em falta?

Há ainda outro problema decorrente da utilização da tabela de Tracking. Quando se acompanha por Percent Complete, o Project faz muitas assumpções de outros campos relacionados com o progresso real. Estamos e facto a recolher a percentagem da duração que está concluída, e desta forma o Project actualiza a Actual Duration e Remaining Duration com base no valor de Percent Complete. Os campos Actual Work e Remaining Work também são valorizados se manteve a opção pré-definida de option 'Updating task status updates resource status', no separador de Calculation das Options do programa.

Na tabela de Tracking podemos ver o Actual Work, mas não está lá o Remaining Work ( na versão pré-definida da tabela. A única forma de o Project re-planear a actividade (ou seja reavaliar a data de Fim) é estimar uma nova quantidade de trabalho que é necessário realizar para completar a actividade.

Quando se decide re-planear a data de fim da Actividade (Finish Date) actualizando o campo da duração restante (Remaining Duration) , o que parece ser o método preferido do Project com base no design da tabela de Tracking, corre-se o risco de modificar o total de trabalho da actividade. Tal ocorre se o tipo de Actividade (Task Type) está estabelecido para Fixed Units (pré-definido no Project) ou Fixed Duration. Ainda é pior se estamos a fazer a monitorização sem utilizarmos a tabela e sem incluirmos nela os campos que necessitamos.

O que deve fazer um P. M.

A verdadeira solução para tudo isto é monitorizar o trabalho realizado e o trabalho em falta (Actual  and Remaining Work) e não o Percent Complete e para fazer isto deve utilizar-se a grelha de tempo e não a tabela de Tracking.

Lembre-se que se não se introduzir valores a 0 para todos os dias em que o trabalho não ocorreu ainda é possível de planear o trabalho em falta. Se está preocupado com a quantidade de trabalho e de tempo que levará para actualizar o plano que contenha muitos recursos e actividades e realizar estas tarefas de forma regular.

Enfim

A linha de orientação é que para que o Project calcule com eficência e exactidão o plano:

Crie uma vista que mostre a informação crítica e que reflicta o progresso real e o trabalho que falta realizar.

• Recolha o trabalho realizado de acordo com o tempo.
• Recolha o trabalho em falta.
• Re-planeie o trabalho em falta

Como criar o Plano Financeiro do Projecto

Passo 1: Listar as Despesas Financeiras do Projecto

O primeiro passoi tomado quando se define o Plano Financeiro e se estabelece o orçamento do projecto é identificar todos os tipos de despesas que que podem ser incorridas durante o Ciclo de Vida do Projecto.

Muitos projectos, tipicamente, gastam a maioria do seu orçamento na compra, aluguer e arrendamento ou contratação de recursos para o projecto (como trabalho, equipamento e materiais). Contudo podfem ser realizadas outros tipos de despesas que se relacionam com:

• Compra de recursos de fornecedores
• Estabelecimento de um Project Office
• Administração do projecto

Passo 2: Quantificar as Despesas Financeiras

Logo que tenha identificada uma lista detalhada de despesas que serão realizadas durante o projecto, o proóximo passo será prever a unidade de custo de cada despesas listada na relação acima efectuada. A unidade de custo é simplesmente o custo de uma unidade singular de um item particular de despesa. Por exempo, a unidade de custo para:

• Trabalho pode ser calculado como custo de hora fornecida
• Equipamento pode ser calculado como o custo de arrendamento por dia
• materiais pode ser calculado como custo de compra por quantidade 

Depois de listar os custos unitários pode então calcular a quantidade total de cada item de despesa nécessária para realizar o projecto. Por exemplo:

• Identificar o número de funções exigidas
• Quantificar os itens de equipamento necessários
• Determinar a quantidade de materiais requerridos
• Quantificar os itens de compras que devem ser recebidos de fornecedores 
• Calcular Os custos de administração do projecto

Passo 3: Construir o agendamento da despesa

Recolhemos então toda a informação necessária para construir um agendamento detalhado da despesa. Este agendamento permitirá ao Gestor de Projecto calcular o custo total para realizar o projecto numa base diária, semanal ou mensal.

Para criar o Agendamento da Despesa, construa uma tabela que liste todos os tipos de despesas do lado esquerdo da página e todas as semanas do ano na coluna da frente. Identifique depois para cada semana e cada tipo de despesa a quantidade de despesa financeira a orçamentar. Quando terminar, pode somar todas as despesas de uma semana particular para obter um orçamento semanal de todo o projecto.

Claro que pode querer calcular uma visão diária, mensal ou anual com base nas necessidades próprias do seu projecto. E não esqueça ainda de listar as assumpções feitas durante a criação deste Plano Financeiro. Por exemplo, pode ter assumido que:

• "As data de entrega dos resultados não sofrerão alteraçõesdurante o projecto."
• "As previsões de unidades de custo estão exacatas dentro de uma variação de 5%."
• "Os fundos financeiros listados no plano estarão disponíveis quando necessário."

Finalmente, liste quaisquer constrangimentos identificados durante o processo de planeamento financeiro. Como por exemplo:

• "A informaçõo disponível era l,imitada durante a identificação dos custos"
• "Uma retração do mercado provocou um acréscimo nos custos do trabalho"

Passo 4: Definir o Processo Financeiro

Depois da criação do Agendamento das Despesas pode necessitar de definir o processo de monitorização e controlo das despesas  (i.e. custos) durante o Ciclo de Vida do Projecto. Definir o Processo de Gestão do Custo do seu projecto através da documentação de:

• Propósito do processo
• Passos envolvidos na realização do processo
• Funções e responsabilidades envolvidas na realização do processo
• Modelos utilizados para suportar o processo

Chegámos ao fim. Concluondo estes passos pode construir um Plano Financeiro adequado que o auxilie a disponibilizar os resultados do projecto em tempo e no orçamento.

Como definir o âmbito do projecto

 

O âmbito do projecto (project scope) é composto por todas as coisas que devem ser produzidas para completar o projecto. Estas «coisas» são denominadas resultados (deliverables) e precisamos de as descrever em profundidade tão cedo quanto possíveol na vida do projecto, para que todos saibam o que é necessário ser produzido. Estes são cinco passos para definir o âmbito dos seus projectos:

Passo 1: Definir a Direcção

Comece por estabelecer a direcção do projecto. Já possui uma visão do projecto acordada pelos stakeholders, sabe os Objectivos e a Escala de Tempo? Foram definidos com profundidade e o cliente concordou com eles? Será que já toda a gente no projecto os compreende verdadeiramente e a razão da sua importância? Só estabelecendo a direcção para o projecto pode definir o âmbito do projecto.

Passo 2: Workshops de âmbito

O caminho para alcançar bons resultados com a definição do âmbito do projecto é obter a ajuda de todos os stakeholders importantes na sua concretização. Para isso, reuna na mesma sala o sponsor do seu projecto, o cliente e outros stakeholders e realize um work shop de identificação do âmbito.

O que pretende deles é que concordem num conjunto de garndes resultados (deliverables) que devem ser produzidos pelo projecto. Também quer saber «o que está fora do âmbito».

Comece o workshop colocando  a cada stakeholder qual a lista de resultados que cada um expera ´que a equipa obtenha com o projecto.

Com esta lista completa obtida da discussão procure obter o assentimento colectivo relativamente ao que é «mandatório» e ao que é «opcional». No final procure priorizar a lista, para poder saber a ordem de produção dos resultados.

Passo 3: Esclareça tudo

Possui agora uma lista acordada de resultados do projecto. Necessita definir em profundidade cada uma destas.

Trabalhe com as pessoas adequadas na sua para descrever como cada resultado deverá ser apresentado e o que deverá incluir, como irá operar e como será suportado, etc. Mas isto ainda não é suficiente!

O seu objectivo é tornar tudo tão específico que o seu cliente não possa declarar maios tarde no projecto que «quando diziam isto, afinal pretendiam significar aquilo».

Passo 4: Avaliar a Viabilidade 

Tem agora uma lista detalhada e a descrição de todos os resultados a serem produzidos no seu projecto ordenados por prioridade e separados por mandatórios / opcionais.

Muito bom! Mas será isto viável de alcançar dentro da dta de fim prevista para o projecto? Antes de confirmar o âmbito, é necessário rever cada resultado da lista e obter uma indicação geral da equipa relativamente a se todas podem ser completadas antes da data de fim. Se não puderem, então quais os resultados que podem ser removidos da lista para permitir que a data de fim possas ser cumprida?

Passo 5: Preparar o arranque

Apresente o conjunto priorizado de resultados ao Sponsor do Projecto e peça-lhe para aprovar a lista como o âmbito do projecto. Peça-lhe ainda que ele concorde com as priroridades, com as descrições de rsultados e com os itens considerados fora do âmbito.

A obtenção de uma aprovação formal coloca-nos numa posição muito boa para gerir o âmbito do projecto de acorod com o camin ho definido. Assim , quando o Sponsor nos diz após algumas semanas ”Pode adicionar mais estes resultados à sua lista?”, pode responder dizendo “Sim, mas ou removemos alguns itens da lista para isso ou alargamos a data de fim do projecto. Qual é que vai ser?”

Pode facilmente gerir as expectativas do Sponsor com um documento detalhado de âmbito na sua mesa.

O documento de âmbito é a armadura do Gestor de Projecto. Protege-o das alterações e fá-lo sentir-se invencível.