blog.tenstep.com.br

Não é óbvio que a maioria dos problemas encontrados em um projeto, tende a aparecer nas fases de construção e de testes? Na realidade, alguns gerentes de projeto apressam propositadamente o planejamento, a análise e o design, porque eles calculam que encontrarão alguns erros na fase de testes.

Infelizmente, quanto mais tarde você descobrir os erros em seu projeto, mais dispendioso será e mais tempo você levará para resolvê-los. Quando você estiver criando o seu Cronograma, invista mais tempo nas áreas de preparação e planejamento, isso salvará tempo e custo no seu projeto. Por exemplo, investir mais tempo na fase de planejamento, economizará o tempo na fase de análise. Investir mais tempo na fase de análise, fará com que o trabalho de design seja executado com menos problemas. Investir mais tempo nas revisões das entregas, resultará em achar os erros mais cedo e economizará tempo na fase de testes. Testar completamente, resulta em salvar tempo na fase de implementação e subseqüentemente no suporte. É claro que você não deseja planejar nem analisar excessivamente. Mas seja diligente neste trabalho. Não se apresse. O tempo investido no início é compensado mais tarde durante o ciclo de vida do projeto.

Criar um cronograma de curto prazo para guiar os processos de definição e de planejamento

O processo de criação dos documentos “Termo de abertura do projeto” e do “Cronograma”, poderá requerer um longo tempo e ser muito complicado. Então, este processo deve ser bem organizado. Após o gerente do projeto ser designado, ele deverá criar imediatamente um cronograma de curto prazo para planejar e gerenciar as atividades iniciais. Este Cronograma inicial, deverá abranger o tempo necessário para criar o documento “Termo de abertura do projeto” e o Cronograma do Projeto. Se este processo requerer duas semanas, o gerente do projeto deverá criar um Cronograma provisório que abranja no mínimo duas ou três semanas. Se o tempo necessário para criar o documento Termo de abertura do projeto e o Cronograma final for quatro semanas, este Cronograma inicial deverá abranger no mínimo quatro semanas, mas poderá fazer sentido criar um plano que abranja cinco ou seis semanas. Este Cronograma provisório, deverá abranger tudo nas atividades iniciais em termos de organização e planejamento do projeto, até que o Cronograma formal do projeto esteja completo para guiar o restante do projeto.

Determine se as horas atuais de esforço serão capturadas

Capturar as horas atuais de esforço do projeto e documentá-las no Cronograma, esta é uma decisão que deve ser tomada cedo no projeto. Por exemplo, você estimou uma atividade para 40 horas de esforço e dez dias de duração. Quando a atividade estiver concluída, você poderá facilmente comparar a duração estimada com a duração atual. Mas, você irá monitorar as horas de esforço para saber se realmente a atividade utilizará 40 horas? Capturar as horas atuais do esforço requer muito mais diligência da parte da equipe do projeto para documentar exatamente o tempo utilizado para cada atividade e relatar. Há muito valor associado à capturação das horas atuais do esforço, incluindo a ajuda para fazer as estimativas futuras com mais precisão. Entretanto, muitas organizações não capturam as horas atuais de esforço. Se a sua organização não capturar as horas atuais de esforço, será difícil para o gerente do projeto reforçar esta disciplina. Coletar as horas atuais de esforço, geralmente é algo requerido (ou não) pela empresa.

Tenha cautela em relação à folga em demasiado no cronograma

Como descrito antes, normalmente há somente um caminho no Cronograma que não tem folga. Este é o caminho crítico e o mesmo controlará a data final. Embora todos os outros caminhos no Cronograma tenham alguma folga, poderá haver alguma preocupação se houver folga em demasiado. O termo “Folga em demasiado” significa que os outros caminhos têm muitos intervalos onde nenhum trabalho necessita ser feito. Isso poderá conduzir a um diagrama de rede longo e magro. Claro, poderá não haver problema com esta ocorrência. Entretanto, as implicações potenciais em relação as folgas em demasiado no Cronograma, são como seguem:

- Muitos recursos humanos vão e voltam (rotativo) ao projeto. Isso poderá causar problemas para assegurar que todos os recursos humanos estarão disponíveis quando necessários e pelo tempo que for necessário. Particularmente, você deverá assegurar-se de que os recursos humanos que serão utilizados no caminho crítico e também utilizados em outros caminhos, tenham trabalho atribuído também nos períodos das folgas.

- Poderá haver falta de senso de urgência pela parte de todos os recursos humanos que não estão trabalhando no caminho crítico. Ou seja, você tem um ou mais recursos humanos trabalhando muito nas atividades do caminho crítico para alcançar os prazos finais, enquanto que todos os outros recursos têm muitas folgas em seus cronogramas. Isto poderá desmotivar muito os recursos humanos que trabalham no caminho crítico.

Tenha cautela em relação a falta de folga no cronograma

Mesmo que haja riscos associados a folga em demasiado, também haverá algum risco associado à falta de folga. Nesse caso, alguns pequenos resvalamentos nos caminhos que estão fora do caminho crítico, poderão transformá-los em caminhos críticos. Então, seria melhor se o Cronograma do projeto, pudesse ser programado de tal maneira que os caminhos que não são críticos, fossem com a menor folga possível “mas não com folga zero” e de modo que os recursos humanos associados aos caminhos, pudessem ser utilizados continuamente no projeto.

Para maiores detalhes sobre o planejamento do cronograma, veja >> Construir o Cronograma e o Orçamento

1 comentário »

Você deve sempre esforçar-se para estabelecer com cuidado as expectativas, e então atender a essas expectativas. Você provavelmente já deve ter ouvido falar que é “Melhor prometer menos, e entregar mais”. Na verdade, esta frase é valida somente em termos de gerenciamento da qualidade, se a mesma se referir a sua capacidade para entregar o produto ou entregar o serviço mais cedo do que o prometido, ou entregar o serviço por um custo menor do que o estimado. No entanto, não é um procedimento correto entregar mais do que foi solicitado pelo cliente, mesmo que seja em nível de qualidade.

O termo “banhando em ouro” refere-se a entregar mais do que o cliente solicitou. Embora pareça ser uma coisa boa, na verdade não é. Isso é errado por dois motivos.

Primeiro, o foco principal do projeto deve ser sempre em assegurar de entregar o que o cliente solicitou – dentro do prazo e do orçamento. Acrescentar trabalho adicional, aumenta o risco do projeto não cumprir com o prazo ou com o orçamento. Se você perder a data final do projeto, não será convincente explicar para o cliente que o prazo foi perdido devido ao acréscimo de trabalho não solicitado.

Segundo, se você adicionar mais trabalho, para entregar mais, você estará assumindo a responsabilidade de decidir sobre o que será mais valioso para o cliente. O cliente poderá ter bons motivos pelos quais as características adicionais não foram incluídas no escopo do projeto. Na verdade, elas podem ter um valor mínimo no ponto de vista do cliente. Poderá ser mais valioso para o cliente ter o produto ou a solução do projeto implementada mais cedo e com menor custo. A questão é que essa decisão cabe ao cliente e não ao gerente do projeto.

Se você prometer menos e entregar mais, isso deverá ser aplicado somente em relação as entregas do projeto, entregar mais cedo ou por um custo menor do que o previsto. Não se deve englobar a entrega de requisitos que não foram solicitados.  De fato, o cliente poderá solicitar a inclusão de requisitos adicionais no projeto, porem os novos requisitos deverão ser processados através de um processo de gerenciamento de mudanças do escopo. Se você puder entregar o projeto mais cedo ou por um custo menor, deixe que o cliente tome a decisão sobre o que fazer com a boa sorte.

Assegure-se de que o gerenciamento da qualidade foca nos processos e não nas pessoas

O foco do gerenciamento da qualidade é em construir processos de forma que toda a equipe do projeto possa produzir entregas que atendam as expectativas do cliente. Assim, se alguma entrega apresentar problemas em termos de qualidade, o gerente e a equipe do projeto devem focar em como aperfeiçoar os processos e não em determinar quem é o culpado.

Muitos dos problemas relacionados à qualidade resultam dos processos inadequados ou insuficientes, e não por má-fé de uma pessoa em particular. De fato, no mínimo 80% dos problemas relacionados à qualidade podem ser resolvidos através das mudanças e de reforços dos processos. Menos de 20% dos problemas estão sob o controle de um membro da equipe. Além disso, normalmente os processos que a sua organização utiliza, são determinados pela gerência. Assim, quando os membros da equipe tiverem problemas relacionados à qualidade, é importante que a gerencia identifique os processos envolvidos que estão fracos ou quebrados, e então repare-os. Esta é uma responsabilidade da gerência e não da equipe do projeto. Isso não significa que a equipe não possa ser envolvida. Entretanto estabelecer e forçar os processos do negócio, primeiramente é uma responsabilidade da gerência.

A qualidade é de responsabilidade de todos

O gerente do projeto tem a responsabilidade pelo processo de gerenciamento da qualidade. Alguns projetos possuem uma função específica de auditoria da qualidade ou um especialista em testes.  No entanto, ainda assim você tem pessoas específicas e responsáveis pela qualidade, a qualidade do projeto não é somente de responsabilidade de uma ou duas pessoas - é de responsabilidade de todos. Toda a equipe do projeto, incluindo o cliente, tem interesse em assegurar que o nível da qualidade das entregas produzidas corresponda as expectativas. Também, todos são responsáveis por contribuir com idéias para fazer aperfeiçoamentos dos processos que são utilizados para criar as entregas.

Para maiores detalhes sobre o gerenciamento de qualidade, veja >> Gerenciando a Qualidade.

Sem comentários »

Incidências Problemáticas

Definição: Incidência Problemática é um problema que impede o progresso do projeto e que não pode ser resolvido sem a ajuda externa.

Se surgir um problema que o gerente do projeto e a sua equipe possam resolver, então isso é apenas uma, de muitas chamas que irão aparecer e serão resolvidas durante uma semana normal de trabalho. Entretanto, uma “Incidência Problemática” surge se o problema impedirá o progresso do projeto e se for necessário ajuda externa para resolve-lo. Este tipo de problema necessita ter um processo estabelecido no início do projeto para assegurar que as pessoas apropriadas sejam informadas, e que o problema possa ser resolvido de maneira mais rápido possível. (É muito difícil tentar estabelecer este processo somente após o surgimento do problema!)

Itens de Ação

Um item de ação é o trabalho que requer investigação e execução posterior. Por natureza, os itens de ação normalmente não podem ser planejados com antecedência. Eles surgem durante reuniões ou como resultado secundário de outro trabalho. Um item de ação deve ser registrado e atribuído a um membro da equipe para ser investigado, porque não há conhecimento, técnica ou tempo suficiente para resolvê-lo na hora.

Em muitos casos, os itens de ação são triviais por natureza, mas em outros casos eles podem exigir um trabalho substancial para serem concluídos. Os itens de ação devem ser atribuídos aos membros da equipe, para serem investigados e executados. (Se os itens de ação não serão executados, então, os mesmo não deverão ser chamados itens de ação. Nesse caso, basta anotar que os itens de ação não serão investigados ou executados). Exemplos de itens de ação incluem; o encaminhamento de informações específicas a alguém, organização de uma reunião, fornecer um rápido orçamento para uma tarefa, etc.

Às vezes um item de ação é estabelecido para investigar uma área onde possa haver um problema potencial. Em razão disso, às vezes os itens de ação são misturados com as incidências problemáticas. Mas, isto não é certo. Um item de ação não deve ser confundido com uma incidência problemática. Uma incidência problemática é um problema que causará um impacto negativo no projeto se o mesmo não for resolvido. Um item de ação pode levar à descoberta de uma incidência problemática ou de um risco (uma incidência problemática potencial futura), mas o item de ação em si não é uma incidência problemática.

Existe duas abordagens comuns que são usadas para gerenciar os itens de ação. A melhor delas é documentar os itens como atividades dentro do Cronograma, e atribuir a um membro da equipe para executá-la. Então, a atividade passa a ser gerenciada e acompanhada com o restante das atividades do Cronograma. Em geral, essa é a melhor abordagem a ser seguida, porque esta abordagem mantém os itens de ação em um único lugar e permite ao gerente do projeto, executar a disciplina de conhecimento. (se uma atividade não estiver incluída no Cronograma, a mesma não deverá ser executada).

No entanto, uma outra abordagem popular é documentar, manter e gerenciar os itens de ação em um “Registro dos Itens de Ação”. Este método pode fazer sentido para alguns gerentes de projetos, porque tipicamente os itens de ação são pequenos e insuficientes para serem incluídos dentro do Cronograma.

Oriente os membros de sua equipe sobre quando eles podem tomar decisões

Após enfatizar a importância de levar as incidências problemáticas e as mudanças potências do escopo ao gerente do projeto, isso poderá parecer para alguns membros da equipe, que eles não têm capacidade para tomar qualquer decisão. Você definitivamente não quer passar esta impressão para sua equipe. Como gerente do projeto, você necessita encorajar as pessoas a aceitar as responsabilidades e tomar as decisões quando apropriadas. Isso ajudará a equipe a trabalhar com mais eficiência e permitirá que os indivíduos cresçam profissionalmente.

Como gerente do projeto, você necessita que os membros da equipe assumam todos os problemas do dia-a-dia e levem a você somente itens em caráter de exceção. Da mesma forma, você deverá resolver o máximo que puder, e levar somente exceções ao patrocinador. Em geral, os membros da equipe devem fazer algumas perguntas básicas a si mesmos antes de decidirem se precisam de ajuda ou se os mesmos podem tomar uma decisão. As perguntas que os membros da equipem devem fazer são:

- Há impacto no esforço, na duração ou no custo do projeto? Se houver, o gerente do projeto deverá ser envolvido.

- As decisões exigirão que você saia do escopo ou desvie de especificações previamente acordadas? Em caso positivo, o gerente do projeto deverá ser envolvido.

- A decisão poderá ter reflexos políticos? Em caso positivo, o gerente do projeto deverá ser envolvido.

- A decisão fará com que você perca algum compromisso previamente acordado? Em caso positivo, o gerente do projeto deverá ser envolvido.

- A decisão irá expor o projeto em risco futuro? Em caso positivo, o gerente do projeto deverá ser envolvido.

Se nenhuma dessas condições for positiva, então o membro da equipe poderá tomar a decisão. Poderá parecer que não sobra mais nada, mas na verdade a maioria das decisões que se fazem necessárias de forma diária não se enquadram nesses critérios e podem ser tomadas pela equipe ou por  um membro da equipe.

Identificar as Soluções Juntamente com as Incidências Problemáticas

As Incidências problemáticas podem ser levantadas pelos membros da equipe, pelos clientes ou por quaisquer partes interessadas do projeto. É uma boa prática encorajar as pessoas a ajudar na identificação das soluções juntamente com as incidências problemáticas. Assim, quando um membro da equipe identificar uma incidência problemática em potencial, peça a ele que traga também uma ou mais soluções possíveis. Esse processo ajudará a estabelecer responsabilidade entre os membros da equipe, mas também ajudará a determinar possíveis cursos de ação. Na verdade, se uma ou mais soluções for viável, o problema poderá ser resolvido com a ajuda do gerente do projeto e nunca chegar ao nível de uma incidência problemática.

Para maiores detalhes sobre o gerenciamento de incidências problemáticas veja >> Gerenciando as Incidências Problemáticas

Sem comentários »