Administração da Alteração de Escopo

O processo de desenvolvimento de produto, tal como um sistema interativo e de longa duração, supõe que sofra alterações no seu curso, objetivos e parâmetros no seu decorrer. Segundo Brigantini e Ribeiro (2005), é incontestável que as alterações de escopo irão ocorrer durante o processo de desenvolvimento. Podem ocorrer de forma mais acentuada nas fases mais tardias do desenvolvimento, conforme citado no processo de desenvolvimento seqüencial ou podem se concentrar como processo de engenharia simultânea nas fases iniciais do desenvolvimento. As solicitações de alteração podem ocorrer por iniciativa interna ou externa, impostas por lei ou opcionais, e podem requerer a expansão do escopo ou sua redução.

A maioria das solicitações de alteração é o resultado de:

- Eventos externos (por exemplo, a mudança de um regulamento governamental);

- Um erro ou omissão na definição do escopo do produto (por exemplo, uma falha em incluir uma característica necessária na elaboração de um sistema de telecomunicações);

- Um erro ou omissão na definição do escopo do projeto (por exemplo, o uso de um BOM em vez de uma WBS);

- Uma alteração visando à adição de valor (por exemplo, um projeto de resolução de problemas ambientais pode gerar redução de custos ao se tirar proveito de uma determinada tecnologia que não estava disponível quando o escopo foi definido inicialmente);

- A implementação de um plano de contingência ou de um plano alternativo para responder a um risco.

Quando modificações de projeto são solicitadas ao longo do ciclo de desenvolvimento, o custo de engenharia tende a aumentar cada vez mais, pois a cada mudança um número maior de decisões já tomadas acaba sendo invalidado (HARTLEY, 1998 in ESTORILIO 2003). O impacto dessas modificações no decorrer do desenvolvimento do produto não se restringe apenas à dimensão custo: tanto no tempo de desenvolvimento, como a qualidade e a integridade do produto também são fatores que acabam sendo prejudicados (CLARK & FUJIMOTO, 1991 in ESTORILIO 2003). Significa dizer, em alguns casos, que algumas alterações exigem o reinício do projeto, ou partes dele. A Figura 5.5. ilustra esses efeitos.

Figura 5.5. Relação entre os retrabalhos e os custos das mudanças de acordo com a fase do desenvolvimento (HARTLEY 1998 in ESTORILIO 2003).

Portanto, apesar de o projeto do produto se desenvolver de forma evolucionária e até mesmo a melhor engenharia não conseguir desenvolver um item sem modificações de projeto, de acordo com Bedworth (1991), estas devem ser minimizadas, principalmente, quando elas atingem um patamar que começa a prejudicar o desempenho do desenvolvimento (ESTORILIO, 2003).

Segundo Rozenfeld et al. (1996), como o processo interativo de projeto inclui o ciclo projeta-testa-otimiza, os custos das alterações (que podem ser otimizações ou correções efetivas) podem ser eventualmente diluídos e pouco visíveis, diferentemente dos processos de manufatura, onde os custos das correções são mais palpáveis – Isso é tão mais verdade quanto mais complexo o produto.

É notório, portanto, por tudo o que acaba de ser descrito, que, embora em algumas situações seja necessário evitá-las, não é possível impedir a ocorrência de alterações, ou mesmo “controlá-las”. Quando tentamos isso estamos indo contra a visão sistêmica do mundo real, ou seja, é impraticável. Entretanto é possível gerenciar estas alterações (ZELLS, 1995 in BRIGANTINI e RIBEIRO, 2005). Apesar desta visão, muitos ainda utilizam ou traduzem o termo como “controle” de alterações de escopo. Isso por si não significa um grande problema desde que todos concordem que estamos nos referindo mais propriamente a um gerenciamento de alterações ou a um controle do fluxo e dos impactos destas alterações.

É preciso, contudo, atentar para o fato de que para se obter melhores resultados dos processos interativos das fases iniciais do projeto, sejam essas interações entre Engenharia do Produto e Processo, seja com os fornecedores ou alterações de estratégias baseadas nos resultados das primeiras avaliações de projeto, é necessário que se realize, ou até mesmo incentive a ocorrência de alterações no início do projeto.

Tennant e Roberts (1999) sugerem, como mostrado na Figura 5.6., essa estratégia para concentrar alterações de projeto (denominados na figura como “desenho”) nas fases iniciais, reduzindo drasticamente seu número de ocorrência no decorrer do projeto e durante e após o lançamento do produto. A proposta de Tennant e Roberts (1999) é que, a partir do meio do projeto, se aumentem os “controles” de alteração – entendendo-se aqui controle como sendo formas de se evitar a implementação das mesmas, somente as permitindo quando plenamente justificadas.

É importante ressaltar que, embora os controles de alteração nas fases do projeto sejam representados como baixos, não significa que não haja nessas fases nenhum gerenciamento, questionamento ou registro das alterações realizadas, que permitam acompanhamento e histórico nas fases posteriores do projeto. Da mesma forma, a aplicação de rígidos controles nas fases mais tardias não sugere a aplicação de um pontodecorteapartirde então não devem mais haver alterações. O que se sugere é umcontrolegradativoqueevitealteraçõesdesnecessárias.Ocontrolesugeretambém que cada pedido de alteração seja devidamente avaliada e oportunidades de melhorias do produto ou reduções de custo possam ser avaliadas a todo momento.

Figura 5.6. Efeitos da Engenharia Simultânea (TENNANT; ROBERTS, 1999)

Tendo em vista a necessidade de conviver com as alterações no decorrer do projeto, Brigantini e Ribeiro (2005) propõe um sistema de gerenciamento das mesmas, como segue.

Todas as alterações deveriam ser documentadas e deveriam, tipicamente, incluir as seguintes informações, antes de serem submetidas para análise:

- Itens da configuração a serem alterados com número de peça e revisão; - Nome da pessoa que propõe a alteração, setor e data;

- Razão para a alteração; - Descrição da alteração; - Urgência.

É recomendado que estas informações sejam colocadas em um formulário padronizado que servirão de documentação dos passos do processo de alteração. Também é recomendado que a alteração tenha um único número de identificação, desde os estágios iniciais para facilitar que ela seja rastreada e identificada. O status do processo da alteração e as decisões e disposições devem ser registradas. Outras informações como: classificação e prioridade devem ser incluídas para indicar o procedimento a ser seguido.

Tipicamente qualquer alteração de configuração terá um impacto em um determinado número de coisas. É recomendado não apenas analisar os méritos técnicos da proposta de alteração, mas também avaliar e documentar o impacto com respeito a:

- Intercambilidade, relação com os elementos a seu redor, etc. e a necessidade de mudança de identificação;

- Contrato, tempo e custo;

- Manufatura, teste, e métodos de inspeção; - Compras e estoque;

- Manutenção, manuais de usuários, peças de reposição e manuais de reposição.

Os critérios de avaliação citados acima devem ser adaptados de acordo com a complexidade do produto do projeto. A classificação da alteração é um método fácil para identificação do processo ou método de aprovação. Eventualmente, propostas de alteração de engenharia requerem a submissão ao cliente. Leffingwell (1997) in Brigantini e Ribeiro (2005) sugere que a interação entre o time de projeto e o cliente seja regulamentada pelos parceiros. O cliente deve, então, assumir alguma responsabilidade oficial para ajudar a gerenciar o escopo do projeto.

Não existe, entretanto, seguro contra o risco associado a alterações de projeto. Gerenciamento total da qualidade e envolvimento dos colaboradores ajudará se ambos, o processo pelo qual o projeto é feito e os entregáveis, forem cuidadosamente analisados pelas equipes que representam os interesses dos maiores interessados nos projetos, as gerências seniores do cliente, o time de projeto e a comunidade. Também, um bom conhecimento dos processos de produção ajudará a evitar algumas alterações relacionadas a manufaturabilidade.

Desde que não é possível evitar alterações, a melhor esperança do gerente de projetos é controlar o processo pelo qual as alterações são introduzidas e completadas.

Meredith (2000) in Brigantini e Ribeiro (2005) diz que isso é conseguido com um processo formal de alterações que, em algumas indústrias, é parte do sistema de gerenciamento de configuração responsável por integrar e coordenar alterações por todo o sistema de desenvolvimento de produto. O propósito do sistema formal de controle de alterações é:

- Revisar todas as requisições de alterações do projeto (conteúdo e processos);

- Identificar todos os impactos nas tarefas;

- Traduzir estes impactos em desempenho, custo e tempo do projeto; - Avaliar os benefícios e custos das requisições de alteração;

- Identificar alternativas que podem atingir os mesmos objetivos; - Aceitar ou rejeitar as requisições de alteração;

- Comunicar as alterações para todos os envolvidos;

- Assegurar que as alterações são implementadas adequadamente;

- Preparar relatórios mensais que resumem todas as alterações até aquela data e os impactos no projeto.

As seguintes recomendações, aplicadas com razoável rigor, podem ser usadas para estabelecer um procedimento efetivo de controle de alterações:

- Todos os contratos ou acordos devem incluir uma descrição de como as requisições de alteração no plano do projeto, investimento, tempo e / ou entregáveis serão introduzidas no processo;

- Qualquer alteração no projeto será feita através de uma ordem de alteração que incluirá descrição do que foi acordado sobre alterações no plano, investimento, tempo e / ou entregáveis resultantes da alteração;

- Alterações devem aprovadas, por escrito, pelo cliente, assim como, por um gerente sênior da empresa responsável pelo projeto;

- O gerente do projeto deve ser consultado sobre qualquer desejo de alteração no projeto, antes da preparação e aprovação da ordem de alteração. A aprovação do gerente de projeto, entretanto, não é requerida;

- Uma vez que a ordem de alteração foi finalizada e aprovada, o plano do projeto deve ser alterado para refletir a alteração, e a ordem de alteração torna-se parte do plano do projeto.

Em projetos maiores vários autores sugerem a adoção de um comitê de controle de alterações, que é um grupo representando todas as partes interessadas que processam todas as solicitações de mudanças.

Zells (1995) diz que existem diversas opções para isso que dependem do tamanho e do tipo de projeto:

- Comitê de análise de solicitações: normalmente utilizado em projetos grandes;

- Análise feita pelos times de manutenção: normalmente utilizado quando a organização tem um time de manutenção separado do time de projetos; - Time de projeto: normalmente utilizada em projetos menores ou quando o time de trabalho pode arcar com esta tarefa adicional;

Já segundo Kezner (2002) in Brigantini e Ribeiro (2005), algumas empresas criam um comitê de controle de configuração e ou mudança, para regulamentar e acompanhar o processo de mudanças. Quando se tratam de mudanças direcionadas aos clientes, estes participam como membro do comitê de controle de configuração.

Este comitê necessita responder três questões básicas a seguir relacionadas: - Qual é o custo da mudança?

- Qual é o impacto da mudança nas etapas de projeto?

- Qual é o valor agregado que esta mudança representa para o cliente ou usuário final?

A definição de comitê de controle de mudanças apresentado por Vargas (2000) in Brigantini e Ribeiro (2005) é: um grupo formalmente constituído dos interessados, responsáveis pela aprovação ou rejeição de mudanças nas bases de referência do projeto. Ele ainda faz distinção entre o controle de mudanças de escopo e controle geral de mudanças que mais amplamente seria responsável por todas as mudanças ao longo do projeto.