blog.tenstep.com.br

Fazer Com Que Todos Sejam Responsáveis pelo Processo de Gerenciamento das Mudanças do Escopo

Muitos processos de gerenciamento do escopo funcionam bem ao nível do Gerente do Projeto, mas são comprometidos pelos membros da equipe. Se o Gerente do Projeto reforçar com diligência as regras de mudanças do escopo, o cliente poderá tentar se dirigir diretamente aos membros da equipe para realizar as mudanças. Por exemplo, quando um relatório (pré-definido e acordado pelo cliente) é entregue para revisão, o cliente poderá pedir um segundo relatório para fornecer mais claridade. O membro da equipe poderá concordar com esse trabalho extra (que mostra o “foco no cliente”). O problema é que a atividade é muito demorada, ou os recursos que poderiam ter sido empregados em outro trabalho com alta prioridade, foram absorvidos em atividades que estavam fora do escopo.

A questão é que todos necessitam ser considerados responsáveis pelo processo de gerenciamento do escopo. Os membros da equipe devem compreender o processo e porque o mesmo é importante. A comunidade do cliente deve compreender o processo e a sua importância. Não considere estes procedimentos como sendo de interesse somente do Gerente do Projeto e do Patrocinador. Certifique-se de comunicar os procedimentos a toda a equipe, incluindo o cliente.

Quando os clientes requisitarem mudanças do escopo diretamente aos membros da equipe, o gerente do projeto deve chamar a atenção do gerente do cliente ou do Patrocinador. Quando os membros da equipe se comprometer com o trabalho que está fora do escopo, lide com isso imediatamente. A primeira vez, isso poderá ser considerado como uma questão de treinamento. Na próxima vez será um problema de desempenho.

Assegurar-se que Somente o Patrocinador possa Aprovar Mudanças e Não os Usuários e os Gerentes do Cliente

Um problema típico em um projeto é que a equipe não compreende qual é o papel (em relação ao Gerenciamento de Mudanças do escopo) do patrocinador, do cliente e dos usuários finais. Em geral, o Patrocinador do Projeto é a pessoa que está financiando o Projeto. Se for somente um cliente, ele deverá ser o Patrocinador do Projeto. Provavelmente eles estão no topo da organização e não são fáceis de serem vistos de forma cotidiana. Na maioria dos casos, o patrocinador designa outra pessoa em sua organização para tomar a maioria das decisões no dia-a-dia.

As pessoas com quem a equipe do projeto tende a trabalhar são freqüentemente usuários finais. Usuários finais são as pessoas que utilizam as soluções que o projeto está construindo. Os usuários finais são, normalmente, aqueles que fazem requisições de mudanças do escopo do projeto. Não importa quão importante seja a mudança para um usuário final - os usuários finais não podem tomar decisões sobre mudanças do Escopo e não podem dar a aprovação a sua equipe para fazer mudanças do mesmo.

No processo apropriado de gerenciamento de mudanças do escopo, o patrocinador (ou designado) deve dar a aprovação. Os usuários finais podem solicitar mudanças do escopo do projeto, mas não podem aprová-las. Os usuários finais não podem alocar fundos adicionais para cobrir as mudanças e não sabem se o impacto no projeto será aceitável. Se a mudança for importante o suficiente para o Patrocinador, ele aprovará a mudança, juntamente com o seu orçamento e prazo. Se a mudança não for suficientemente importante, a mesma não será aprovada. Por tanto, será o Patrocinador quem tomará a decisão, e não o Gerente de Projeto, os gerentes do cliente, os membros da equipe ou os usuários finais.

Para Projetos Grandes ou que Envolvem Múltiplos Departamentos, Utilize um Comitê de Controle de Mudanças

Às vezes, em projetos muito grandes, o patrocinador do projeto não se sente confortável para tomar decisões sozinho sobre as mudanças do escopo. Esse poderá ser o caso, se o efeito da mudança impactar outras organizações. Também, poderá ser o caso que múltiplas organizações estejam envolvidas, ou contribuindo com fundos para o projeto e desejam fazer algum comentário ao avaliar as requisições de mudanças do escopo. Para estes casos, um grupo de pessoas poderá ser necessário para manejar o processo de aprovação de mudanças do escopo.

Um nome comum dado a esse grupo é “Comitê de Controle de Mudanças”. Se existir um comitê, poderá ser mais difícil trabalhar. Contudo, o processo geral de gerenciamento da mudança do escopo não necessita mudar dramaticamente. Por exemplo, ainda há um documento que inicia a requisição de mudança do escopo. A equipe do projeto precisa determinar o impacto e o custo para o projeto. O comitê deve avaliar o impacto, o valor em termos de benefícios, o custo, o sincronismo do projeto, etc. e então determinar se a requisição será aceita ou não.

Os procedimentos de mudanças do escopo devem ser mais sofisticados para o comitê. Por exemplo, você necessita esclarecer quem está no Comitê, com que freqüências se encontrarão, como serão notificados em casos de emergências, como tomarão as decisões (consenso, maioria, unanimidade, etc.) e como o trabalho excedente será pago, etc.

Para maiores detalhes sobre Gerenciamento de Mudanças, veja >> Gerenciamento de Escopo.

Sem comentários »

A Análise de Pareto pode ser utilizada quando você encontra vários problemas relacionados ou um problema comum com múltiplas causas. Com esta técnica, você coleta métricas sobre quantas vezes ocorre cada problema ou a causa. O objetivo da Análise de Pareto é observar os problemas e determinar sua freqüência de ocorrência. Isso, por sua vez, lhe proporcionará as informações necessárias para priorizar o seu esforço para garantir que você está utilizando seu tempo onde obterá o impacto mais positivo.

A Análise de Pareto se baseia na clássica regra 80/20. Em outras palavras, 20% das ocorrências causam 80% do problema. Por exemplo, digamos que você tem um problema relacionado com a falha de um produto baseado em um número de causas. Através da observação e coleta de métricas, você determina que há oito causas. Em vez de tratar as causas de forma aleatória, uma Análise de Pareto poderá lhe mostrar que 80% dos problemas são provocados por três maiores causas. Isso lhe dá informações para saber quais as causas deverão ser resolvidas primeiro.

A ferramenta associada a essa técnica de solução de problemas é o Diagrama de Pareto. O Diagrama de Pareto é um mapa, gráfico ou histograma mostrando cada problema e a freqüência com que o memo ocorre. É criado como segue:

1. Crie uma tabela listando todos os problemas ou causas observadas.

2. Para cada problema, identifique o número de ocorrências por um período fixo de tempo.

3. Ordene os problemas por número de ocorrências, do mais alto ao mais baixo.

4. Acrescente uma coluna para o subtotal.

Note que isto nos traz informações importantes. Embora haja seis problemas identificados no total, você precisa resolver primeiro os problemas n°1 e n°3. É aí que você terá o maior impacto. Se em vez disso você decidisse trabalhar nos problemas n°4 e n°5, o resultado do seu esforço seria quase desprezível. Isso não significa que você não queira resolver os demais problemas. No entanto, a Análise de Pareto lhe fornece informações sobre a ordem em que eles devem ser enfrentados. Ela também lhe dá uma idéia do valor relativo que você obtém em resolver cada problema. Definitivamente você não quer exercer o mesmo esforço resolvendo o problema n°5 como faria no problema n°1. O retorno não é o mesmo. (Naturalmente, você poderá determinar que o problema n°6 pode ser resolvido rapidamente e você poderá decidir resolve-lo mais cedo. O diagrama de Pareto não lhe diz o que fazer, mas lhe fornece a informação de modo que você possa tomar as decisões de forma mais efetivas.)

Muitas vezes, você verá os resultados de um Diagrama de Pareto mostrados como um histograma ou diagrama de barras. Isso dá mais ênfase visual aos dados que você observou.

Para maiores detalhes sobre Gerenciamento de Incidências Problemáticas, veja >> Gerenciamento de Incidências Problemáticas.

Sem comentários »

As premissas estão muito relacionadas aos riscos, e, de fato, são simplesmente riscos de nível baixo. Ambos começam com a mesma premissa. São eventos ou circunstâncias futuras que impactarão seu projeto. Em ambos os casos, há uma probabilidade de ocorrência e de um impacto em seu projeto. A diferença entre uma premissa e um risco está na combinação da probabilidade e do impacto e se os mesmos são aceitáveis ou não.

Tomamos uma proposição comum que está incluída em muitos dos documentos de “Definição de Projetos” – “Os recursos necessários para este projeto estarão disponíveis quando forem requeridos”. Que tipo de proposição é esta? A maioria das pessoas diria que é uma Premissa. Apesar de tudo, quando um projeto inicia, sempre supomos que conseguiremos os recursos que necessitamos.
Entretanto, isso realmente é uma Premissa? Você imagina começar um projeto onde as pessoas e os equipamentos não estejam disponíveis e, de fato, existe uma possibilidade realística de não estarem prontos quando você os necessitar - talvez porque outros projetos precisam ser concluídos antes. Não é muito difícil imaginar este cenário. Neste caso, a mesma proposição seria definitivamente um risco e não uma Premissa.

O ponto-chave é que a mesma proposição pode ser uma Premissa ou um risco, dependendo das circunstâncias do seu próprio projeto. A diferença entre uma premissa e um risco é se a combinação da probabilidade e do impacto é aceitável. Se o evento tiver um impacto negativo no projeto, mas houver uma baixa probabilidade de ocorrer, ele poderá ser considerado uma Premissa. Se o evento tiver um impacto positivo no projeto, mas houver uma alta probabilidade de ocorrer, ele também poderá ser considerado uma Premissa.

Uma forma de identificar as Premissas importantes é executar uma avaliação de riscos e analisar todos os riscos que forem indicados como um risco de nível baixo. A maioria destes riscos não merece ser mencionados, mas alguns terão implicações significativas se os eventos não se desenrolarem como você imagina. Estes são aqueles que você poderá documentar como Premissas. Para melhores detalhes sobre avaliação de riscos veja a seção 7.1.1 Gerenciando Riscos / Processo / Projetos Médios e  7.2.1 Gerenciando Riscos / Técnicas / Fatores de Riscos Inerentes.

Há duas características chaves sobre os riscos e as Premissas. Primeira, haver algum nível de incerteza sobre o evento. Se o evento tiver 100% de probabilidade de ocorrer, ele é simplesmente um fato. Se o evento tiver 0% da probabilidade de ocorrer, ele é simplesmente uma ficção. Então, nenhum deles é um risco ou Premissa.

Segunda, as Premissas e os riscos estão fora do controle da equipe de projeto. Se o evento estiver dentro do seu controle, então ele não é uma Premissa e nem um risco. Ele simplesmente deverá ser gerenciado e incluindo no seu cronograma.

Para melhores esclarecimentos sobre Premissas e risco, veja os seguintes exemplos:

Para maiores detalhes sobre Gerenciamento de Riscos, veja >> Gerenciamento de Riscos.

2 comentários »