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.