blog.tenstep.com.br

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 »

Assegure-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 apenas 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 de 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) é quem 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.

Deixe que o patrocinador tome as decisões, normalmente ele não tem problema em dizer não

Uma das coisas fundamentais em reforçar a disciplina de ter o Patrocinador aprovando as mudanças do escopo, é que, a não ser que a mudança seja muito importante, mas, normalmente o patrocinador dirá “não”. Mais uma vez, o patrocinador geralmente é alguém em posição elevada na organização e não quer ouvir sobre requisições de mudanças pequenas do escopo. Eles querem o projeto original cumprido de acordo com os compromissos originais relativos ao custo, esforço e duração. Mesmo que seja difícil para o Gerente do Projeto dizer “não”, o Patrocinador do Projeto normalmente não tem nenhum problema em dizer.

Crie uma lista de pendências de requisições de mudanças que não são aprovadas durante o projeto

É possível que o patrocinador não aprove requisições de mudanças do escopo durante o projeto, mas poderá existir requisições válidas que poderão ser executadas mais tarde. Este tipo de requisições de mudanças deve ser colocados numa lista de pendências. Depois que o projeto for completado e a solução for transferida para o departamento de suporte, poderá haver uma oportunidade para fazer aperfeiçoamentos, ou estabelecer um projeto como fase II. Novamente, estas mudanças serão implementadas somente se forem aprovadas pelo patrocinador e disponibilizado a verba.

Não utilize a reserva de contingência associada a estimativa do projeto para as mudanças do escopo

Uma das etapas do processo de estimação é adicionar horas de contingência para refletir o nível de incerteza associado com a estimativa. Por exemplo, se as horas de trabalho forem estimadas em 5.000 horas, você poderá adicionar 500 horas para a reserva de contingência, o que reflete um fator de confiança de 90%. Quando a reserva de contingência for aprovada, haverá uma pressão sobre o Gerente do Projeto para que ele utilize a reserva de contingência na absorção das exigências adicionais. O cliente poderá dizer, “Por que devemos invocar o processo de gerenciamento de mudanças do escopo para esta mudança de 100 horas? Você tem em suas estimativas 500 horas de reserva para contingência!”

O gerente do projeto deve resistir a tentação e a pressão. A finalidade da reserva de contingência é para refletir a incerteza nas estimativas. Haverá muitas oportunidades para utilizar a reserva de contingência quando as atividades requererem mais tempo do que o esperado. Não utilize a reserva de contingência para realizar trabalho extra. Se as estimativas do projeto forem razoavelmente exatas, você deverá enviar a reserva de contingência de volta ao cliente no final do projeto. (ou no caso de um cliente externo, considerá-la como lucro)

Para maiores detalhes sobre o gerenciamento de escopo, veja >> Gerenciando o Escopo

2 comentários »

Definir o escopo talvez, seja, a parte mais importante do processo inicial de definição e de planejamento. Na verdade, se você não souber com certeza o que você entregará e quais são os limites do projeto, você não terá qualquer possibilidade de sucesso. Se você não realizar um bom trabalho para definir o escopo, o gerenciamento do mesmo será quase impossível.

A finalidade de definir o escopo é para descrever claramente e obter um acordo sobre os limites lógicos de seu projeto. As declarações do escopo são utilizadas para definir o que está dentro dos limites do projeto e o que está fora. Quanto mais aspectos do escopo você puder identificar e definir, melhor será seu projeto. Os seguintes tipos de informação podem lhe ajudar na definição do escopo:

As entregas que estão dentro do escopo e as que estão fora do escopo. Você deve definitivamente incluir as entregas dentro da sua declaração do escopo. Mas descreva somente as entregas finais e outras entregas do projeto que são focadas no cliente. Por exemplo, Relatórios das “Exigências do Negocio” e “Avaliação da situação atual” podem ser listadas como entregas do projeto, porque ambas são focadas e aprovadas pelo cliente. Você não necessita mencionar os documentos internos. Por exemplo, o cronograma do Projeto, Design Técnico ou Casos de testes.

Os principais processos do ciclo de vida do projeto que estão dentro e os que estão fora do escopo. Por exemplo, seu projeto pode incluir somente a fase de análise e não as fases de design, construção e testes.

Os tipos de dados que estão dentro e os que estão fora do escopo. Os tipos de dados referem-se as categorias de dados, tal como dados financeiros, vendas e empregados. É possível que seu projeto inclua somente alguns tipos de dados e outros não.

As fontes de dados (ou bases de dados) que estão dentro e as que estão fora do escopo. Este é similar aos tipos de dados, exceto que este referencia os dados agregados. Por exemplo, base de dados dos clientes, Faturamentos, Livro-Razão, etc. (Estas fontes de dados podem ter mais de um tipo de dados)

As organizações que estão dentro e as que estão fora do escopo. Por exemplo, seu projeto pode focar somente nos departamentos de Recursos Humanos e Financeiro e os outros poderão estar fora do escopo.

A funcionalidade principal das aplicações dos sistemas que estão dentro e as que estão fora do escopo. Por exemplo, os relatórios gerenciais podem estar dentro do escopo, mas o processamento de dados em lotes noturno estar fora do escopo.

Use Objetivos Elevados Como Ponto de Partida

Quando o projeto foi apresentado para fins de financiamento, deveria haver um grupo de objetivos e de entregas definido em um nível elevado. Também Poderia haver algum tipo de declaração do escopo em um nível elevado. Todas as informações criadas anteriormente devem ser usadas como um ponto de partida para definir as declarações mais detalhadas do escopo. Se você achar que não possui informações suficientes para criar um escopo abrangente e claro, trabalhe com o patrocinador para coletar informações adicionais. Esta é uma das finalidades do processo de definição e planejamento.

Utilize os objetivos para ajudar a moldar as declarações do escopo. Por definição, deverá haver uma ou mais entregas criadas para realizar cada objetivo. A definição das entregas do projeto é um dos aspectos principais do escopo do projeto. Depois que você determinar quais são as entregas principais que o projeto produzirá, comece a fazer outras perguntas para determinar outros aspectos do escopo. As entregas descrevem “o quê” o projeto entregará. Você também pode identificar “quais” organizações sofrerão o impacto, “que” tipo de dados serão necessários, “que” características e funções serão necessárias, etc.

Para maior clareza e contraste, você também poderá identificar condições que estão FORA do escopo, descrevendo as entregas que não serão criadas, as organizações que não serão impactadas, as características e as funções que não estão incluídas, etc. Naturalmente há um número infinito de declarações fora do escopo. Para as finalidades de definição do escopo, você quer incluir somente aquelas declarações que lhe ajudam a definir os limites do projeto, e tocar naquelas áreas as quais o leitor possa ter perguntas. Por exemplo, se você tiver que instalar um software financeiro, você poderá declarar que um pacote de “Contas a Pagar” está dentro do escopo, mas que o Sistema de “Compras” relacionado ao mesmo está fora. Isto fará sentido desde que os processos de “Compras” e “Contas a pagar” sejam relacionadas entre si e poderá haver interrogações sobre o sistema de compras, se o mesmo está dentro ou fora do escopo. Mas você não deve listar todos os outros sistemas que estão fora do escopo – somente aqueles que os leitores poderão questionar.

Uma boa prática é documentar as organizações que estão dentro do escopo e aquelas relacionadas que estão fora do escopo. Os leitores poderão, então, determinar com maior facilidade se serão impactados, ou se ajudarão no projeto. Também, pode fazer sentido identificar quais as organizações que estão dentro do escopo, de modo que você possa ter pessoas daquelas organizações representadas na equipe do projeto - talvez em um comitê de direção.

Alinhando os Objetivos e o Escopo

Quando você terminar de documentar os seus objetivos e as declarações do escopo, retorne e certifique-se de que eles estão todos alinhados. Você não deve ter nenhum objetivo referente as entregas que não esteja definido no escopo. Se o projeto não esta criando alguma coisa para satisfazer um objetivo, o projeto não poderá completar com sucesso o objetivo.

Da mesma maneira, você não deve incluir entregas em seu projeto que não o ajudem a alcançar seus objetivos.  Se você propor-se de construir as entregas que não lhe ajudam a conseguir os objetivos do seu projeto, você deverá perguntar-se por que. Assim como os objetivos descrevem a finalidade do projeto, por que você construiria entregas que não lhe ajudarão a conseguir seus objetivos?

Se os objetivos e as entregas na seção do escopo do projeto não são alinhados, você necessita determinar como alinhá-los.

- Se você tiver um objetivo sem uma entrega, você necessita validar se o objetivo realmente é importante. Se for, então você terá que adicionar ou modificar as entregas para satisfazer o objetivo.

- Se você tiver uma entrega sem um objetivo associado, então você terá que perguntar se a entrega realmente é importante. Se não for, remova-a do projeto. Se a entrega for realmente importante, você deverá trabalhar com o patrocinador para determinar o objetivo para criá-la.

Para maiores detalhes sobre Comunicação, veja >> Definir Tarefas.

Sem comentários »