Controlar os pedidos de Alteração nos projectos

Os pedidos de alteração quando um projecto se inicia são uma parte inevitável do projecto. Elas podem ser o resultado de mudanças externas no negócio ou podem ser mudanças internas requeridas porque os propósitos originais do projecto não foram claramente definidos ou compreendidos.

As mudanças requeridas por factores externos estão normalmente fora do controlo de um gestor de projecto e há muitas vezes poucas escolhas para as enfrentar. Muitos dos gestores de projecto experimentados terão já colocado em posição um processo no início do projecto para tratar destes pedidos e o plano será suficientemente flexível para tratar delas sem afectar o resultado final.

Mas os pedidos de alteração provenientes de factores internos devem ser tratados de forma muito diferente. Num projecto ideal muitos destes devem ser evitados garantindo que os objectivos do projecto estão bem definidos, que os requisitos estão documentados claramente, que foram comunicados a todos os stakeholders e que estes compreenderam o que é esperado do produto final. Claro que nós não vivemos num mundo ideal e por mais profunda e bem detalhada que sejam as fases iniciais do projecto tem de existir em posição um efectivo processo de controlo da mudança.

Nem todos os stakeholders e utilizadores conseguem visualizar o produto final pela leitura da documentação e estudo de diagramas. Mesmo quando são usados protótipos para melhorar a produção de requisitos, estes são, pela sua própria natureza, produtos não inteiramente funcionais e serão inevitáveis incompreensões e assumpções nos projectos complexos.

De qualquer forma, a boa documentação e documentação clara dos objectivos e requisitos de projecto irão minimizar o número de pedidos de alteração.

Então qual é a melhor forma de controlar os pedidos de alterações num projecto e continuar a realizar a conclusão do projecto dentro de um orçamento, de escalas de tempo e âmbito?

Distinguir entre o Necessário e o «Era bom ter»

Cada um dos pedidos de alteração deve ter uma justificação (que tal um «business case») que os suporte, tal como o projecto tem uma justificação. Claro, que esta justificação pode ser muito simples e breve, mas é um elemento necessário de todos os pedidos de alteração antes que possam ser considerados para inclusão no projecto.
O elemento mais importante deste «business case» do pedido de alteração é o benefício esperado o qual deverá indicar o valor que será adicionado ao projecto pela mudança. Isto indicará, por si próprio, quais as mudanças que serão provavelmente necessárias. É importante reconhecer que a descrição de alguns destes «business cases» pode não beneficiar necessariamente o projecto em termos de tempo e orçamento, mas sejam necessárias para que o cliente se mantenha competitivo no mercado.
Se os benefícios não forem especificamente declarados então deve discutir-se a questão com a pessoa que requereu a alteração para determinar se existe um genuíno benefício de negócio.
Soluções melhor desenhadas, ou mais bonitas, com funcionalidades e mais atractivas não são benefícios, a não ser que possam ser apoiadas pela forma como estas tiveram um impacto positivo no orçamento e no plano do projecto, ou, um impacto positivo nos esforços dos utilizadores em completarem actividades regulares. As perguntas mais vulgares a que deve responder o «business case» são:

• · Qual é a mudança externa no negócio de que resultou este pedido de alteração?
• · Quais os factores internos de que resultou este pedido de alteração?
• · Como é que esta mudança irá afectar o tempo que levamos a completar o projecto?
• · Como irá esta mudança afectar o produto final para o utilizador?
• · Que poupanças serão realizadas pela implementação desta mudança?

Evite desperdiçar Tempo e Esforço

A forma mais óbvia de evitar desperdiçar recursos valiosos de projecto em pedidos de alteração excessivos e em todo o processo de gestão da mudança, é garantir que o projecto se inicia com objectivos e requisitos claramente definidos. É também importante o critério que iremos usar para determinar o sucesso do projecto estar documentado sucintamente desde o início do projecto. Deve garantir que estes documentos são distribuídos aos stakeholders e utilizadores e que estão acessíveis cópias dos documentos.

Planeie actividades incluídas no plano do projecto para tratar dos pedidos de alterações e se este tempo foi ocupado adie os pedidos importantes para a próxima semana. Garanta que todas as partes interessadas sabem como trabalha este processo.

Tenha um Critério Claro de Aceitação e Rejeição

Defina um critério para avaliar estes pedidos que não serão, ou não poderão ser implementados. Quem faz o pedido tem de compreender o critério e este tem de ser consequente. O critério essencial, como já vimos, é ter uma justificação escrita, um «business case», que esclareça os benefícios. Se não tiver pode ser de imediato devolvido a quem emitiu o pedido. Não perca tempo atrás de quem fez o pedido para saber qual é a justificação escrita. A responsabilidade disso é de quem faz o pedido que o deve fazer logo desde o início (mesmo que depois devamos discutir e aprofundar a discussão sobre esta justificação).

Esteja preparado para fundamentar as razões para rejeitar um pedido de alteração com uma descrição bem pensada do porquê para não incluir a mudança. Mantenha-se na sua decisão a não ser que o sponsor do projecto queira aumentar o orçamento ou o tempo disponível no projecto.

Esteja, também, preparado para ser flexível e para negociar a substituição de uma actividade em favor da mudança quando não há nem orçamento nem tempo disponível.
Aplique sempre as melhores práticas de gestão de projecto em todas as áreas do projecto se quer aumentar as suas oportunidades de sucesso.

KPIs de Performance de Projecto

Quais são as mais críticas métricas de performance de projecto ? Com base no plano do projeto podemos identificar uma lista das mais importantes:

• Planeamento – planeado versus real – preferencialmente através do Valor Ganho

• Funcional – % desenhado, implementado, testado, produzido

• Realização em tempo – milestones planeadas versus as milestones reais

• Custo

• Custo planeado versus custo real

• Total Planeado na Conclusão versus Revisto ou estimado na Conclusão

• Crítico e outros defeitos – Planeado versus Real + tendência

• Recursos (Pessoas, Equipamentos)

• Recursos Planeados versus Recursos Reais

• Recursos Totais Planeado na Conclusão versus Revistos ou estimados na Conclusão

• Riscos – Novos, Fechados, Abertos + Tendências

• Questões – Novas, Fechadas, Abertas + Tendências

• Resultados – Planeados versus reias até à data

A standardização dos valores a reportar ajuda a mantermo-nos no caminho certo.
Naturalmente que todas estas métricas são quantificáveis. A informação qualitativa pode ser útil quando preparado no seguimento das métricas acima. Os problemas só começam quando as pessoas começam a esgrimir as suas declarações qualitativas e esquecem-se de colocar no relatório algumas das métricas quantitativas. ~

Luís Quintino

«Almofadas» de tempo no Plano

No mundo da gestão do projeto, as coisas correm mal! Esta é uma característica inerente aos planos, nunca correm conforme planeados. É por isso que bons gestores de projeto irão registar e acompanhar os riscos associados às atividades do projeto. Ainda assim, é difícil encontrar todos os riscos que podem estar escondidos dentro do cronograma do projeto. Por isso que alguns gestores de projeto adotam a prática de adicionar um ‘buffer’ de tempo na programação.

Sim. Tal como uma reserva de gestão ou reserva de contingência está incluída num orçamento como um item de linha, os gestores de projeto podem incluir uma «almofada» (‘buffer’) de tempo como um item de linha na programação. Então estes ‘buffers’ de tempo são uma forma geralmente aceite para explicar questões desconhecidas no cronograma. Se não usar esta «almofada» de tempo como item de linha o mais provável é que, involuntariamente, esconda estes ‘buffers’ de tempo dentro do plano de qualquer maneira.

Vamos discutir estas «almofadas» de tempo nos planos e a prática de as tornar visíveis. Temos de compreender que a sua utilização é outra ferramenta daquelas a que os gestores de projeto podem recorrer.

Deve ou não estar escondida?

A primeira questão é se esta «almofada» deve ser escondida ou deve estar visível. Para projetos de tempo e materiais, de forma definitiva, não faz qualquer sentido esconder este ‘buffer’ já que está garantido o pagamento de todo o tempo gasto no projeto. Mas para contratos de preço fixo, em que nos comprometemos a um custo fixo do projeto e uma data estabelecida de entrega, a existência de um ‘buffer’ escondido pode ser adequada. Geralmente num contrato de preço fixo não se mostra a margem de lucro e isto é uma prática standard aceitável. Da mesma forma pode ser aceitável não mostrar a margem de tempo para a data de fim do projeto.

Se não é utilizado um ‘buffer’ de tempo visível, como descrevemos, então o mais provável é estarmos a esconder ‘buffers’ não declarados. Por exemplo, podemos estra a exagerar o tempo e o custo de atividades individuais. Isto é conhecido como «engordar» as atividades. ‘Engordar’ é a adição de tempo e / ou custo a uma atividade para fornecer uma estimativa conservadora do tempo de atividade e / ou de metas de custo. Assim, «engordar» as atividades é uma das principais formas de ‘buffer’ escondido dentro de um cronograma.

Atitude perante o projeto

Outro processo é ser pessimista. Quando são fornecidas estimativas de duração de três pontos (otimista, mais provável, pessimista), usa-se os valores mais pessimistas para produzir um plano conservador. Mais uma vez, esta é uma forma de ‘buffer’ de tempo escondido. Outros processos, incluem, ignorar as curvas de aprendizagem ou a introdução de ‘ramp-up’ ou fatores de mobilização.

Embora, possa ser legítimo esconder ‘buffer’ num contrato de preço fixo, é recomendável que sempre torne os seus ‘buffers’ visíveis. É prática geralmente aceite que os gestores de projeto podem possuir ‘buffers’ de tempo para ajudar a ajustar para imprevistos.

Mais uma vez, a reserva de gestão de orçamento é uma prática amplamente aceite.

Mudar a atitude dos ‘donos de obra’

Nem sequer é grande extrapolação a partir daqui incluir também contingências orçamentais de tempo. Os ‘buffers’ de tempo visíveis também promovem a transparência e abertura num projeto entre o gestor de projeto e outras partes interessadas. O uso de ‘buffers’ visíveis também incentiva os membros da equipe do projeto a serem abertos e honestos sobre seus próprios ‘buffers’ de tempo.

O objetivo deve ser otimizar a programação para alcançar os objetivos de custo e tempo de uma forma atempada e eficiente. Depois, pode concentrar-se numa margem de segurança, no final da cadeia de projeto e utilizar apenas quando o risco se materializa.