verificação independente

WHITE PAPER

Verificação Independente de Projetos

1

Introdução

A importância da Verificação Independente de projetos

A gestão de projetos tem evoluído bastante nos últimos anos, principalmente após

a organização e divulgação das melhores práticas, treinamento e certificação de

gerentes de projeto.

A Verificação Independente, porém, ainda é pouco divulgada e conseqüentemente

pouco utilizada. Essa prática consiste em contratar consultores externos ao

projeto para verificar sua gestão e andamento, de forma independente, livre das

“paixões” de quem está vivendo o projeto no dia-a-dia. A Verificação

Independente é importante mesmo quando o projeto está bem estruturado e

gerenciado por equipes bem qualificadas.

Imaginando o ambiente de projeto ideal, o gerente de projeto terá no seu dia-a-

dia, o assessoramento do escritório de projetos, PMO, e variadas ferramentas de

controle, o que lhe permite acompanhar as nove áreas de conhecimento

relacionadas no Guia PMBOK: Integração, Escopo, Tempo, Custos, Qualidade,

Recursos, Comunicação, Riscos e Aquisições. No entanto, principalmente nos

projetos mais complexos, o tempo do gestor se aplica na resolução das questões

do dia-a-dia, o que lhe coloca no centro do projeto, de onde não pode ter a

perspectiva externa. Quando o gerente adota a contratação de uma Verificação

Independente, externa, ele terá uma base confiável para a tomada de decisões.

Por manter a visão independente externa, o gerente de projeto poderá separar as

questões do dia-a-dia das questões mais amplas de projeto.

Outro ponto a considerar é que o projeto tem uma responsabilidade limitada

dentro de uma abrangência maior que interessa à empresa, ao cliente e ao

sponsor do projeto. Mesmo que o projeto execute suas atividades muito bem, será

que a empresa está fazendo sua parte, e está se preparando para receber o

WHITE PAPER


2

projeto ao seu final? Esse é um tema que ultrapassa os limites da gestão do

projeto, mas estão nos limites da responsabilidade do sponsor. Uma Verificação

Independente deve também tratar das responsabilidades da empresa e do sponsor,

para que o resultado esperado do projeto possa ser materializado após o seu

termino, como ilustramos na Figura 1.

Figura 1: figura adaptada do original publicado no Guia PMBOK terceira edição

Quando executamos uma Verificação Independente, utilizamos uma metodologia

que divide a análise em três grandes grupos: Project Governance, Project

Management e Change Management, que por sua vez, são subdivididos na seguinte

estrutura:

• Project Governance – Governo do Projeto

o Liderança

� Foco no cliente interno

� Foco no cliente externo

� Foco na contingência

� Foco na capacitação e treinamento

WHITE PAPER


3

o Relação com o Mercado

� Relações Públicas e Comunicação Interna

� Seleção de fornecedores

� Gestão do risco de fornecedores

� Gestão de programas

o Gestão dos Resultados

� Declaração de benefícios

� Gestão do valor

� Gestão do plano operacional

� Controle da complexidade

� Priorização do projeto

• Project Management – Gestão do Projeto

o Risco de Prazo e Orçamento

� Planejamento das atividades

� Gestão de contratos

� Gestão de SLA de Fornecedores

� Participação e controles do projeto

� Gestão do conhecimento e metodologia

� Gestão de recursos humanos

� Controle de custos

� Controle de escopo

o Risco Operacional

� Gestão da qualidade

� Desvios de padrão

� Administração da informação

� Administração de dados

WHITE PAPER


4

� Testes e piloto da operação

� Prova de desempenho

� Prova de usuário

� Infra-estrutura de suporte

� Garantia e operação assistida

• Change Management - Gestão da mudança

o Organização para a mudança

o Gestão do ambiente de trabalho

o Gestão dos impactos

Análise da Governança do Projeto – Liderança Interna

São avaliadas as questões que transcendem à gestão do projeto e que dependem

em muito do sponsor e stakeholders. Temas como sua contribuição na definição do

escopo do projeto e o que estão fazendo para que a empresa esteja pronta para

receber as entregas do projeto ao seu final.

Avaliamos o grau de envolvimento dos Clientes Internos e usuários durante a fase

de concepção do projeto, quando se definem as funcionalidades esperadas e as

regras de negócio que devem ser obedecidas. Depois, durante o projeto,

entrevistamos clientes e lhes perguntamos como estão participando e o quanto

conhecem da solução que será entregue pelo projeto e, dependendo das

respostas, poderemos avaliar o risco de que o projeto não atenda aos reais anseios

da empresa.

Na avaliação do Cliente Externo, incluímos os clientes da empresa ou os

fornecedores que podem ser impactados pelas mudanças introduzidas pelo

projeto, por exemplo, em um projeto de ERP, clientes e fornecedores serão

WHITE PAPER


5

fortemente impactados, seja na forma de relacionamento entre as empresas ou

seja na integração dos seus sistemas. Avaliamos, nestes casos, se a empresa

cuidou de todos os impactos e se estes estão refletidos no escopo do projeto e se

não estão sendo alterados durante a sua execução (desvios de escopo, por

exemplo).

No âmbito de contingência, avaliamos como a empresa lida com a hipótese do

projeto atrasar ou de não chegar a atingir plenamente os objetivos estabelecidos.

Analisamos como a empresa dimensionou esse risco, seus impactos e suas opções

para mitigação ou aceitação do risco.

A liderança se preocupa com a capacitação da empresa quanto ao projeto? Isso

envolve não só a capacitação da equipe de projeto, mas também a estratégia para

treinar os recursos que deverão dar continuidade à solução depois de terminado o

projeto, a manutenção e evolução do sistema, por exemplo, e também, a

capacitação da empresa para poder operar a solução.

Governança e Análise da Relação com o Mercado

Caso o projeto vá alterar a relação com clientes externos e fornecedores, a

empresa preparou a área de relações públicas quanto ao tratamento que deve dar

à imprensa, sindicatos, empregados, fornecedores e clientes? Avaliamos o grau de

preparação da empresa para lidar com a comunicação externa ao projeto,

principalmente nos projetos de grande impacto. Nos projetos de pequeno

impacto, a avaliação não inclui Relações Públicas, mas abrange a área de

comunicação interna da empresa.

Ainda no tema de relação com outras empresas, avaliamos como funcionam os

procedimentos de escolha de fornecedores. Se em alguns projetos a escolha do

fornecedor pode ser feita pelo gerente de projeto, existe, em muitas empresas,

WHITE PAPER


6

uma situação diferente, a mais comum, em que o gerente de projeto só pode

escolher dentre um grupo limitado de fornecedores pré-selecionados ou parceiros

homologados pela empresa. Além disso, um processo bem elaborado de sourcing,

para escolher os fornecedores pode ser um processo longo, que o projeto não pode

acomodar dentro do seu escopo, prazo e custo. Nesse tema, avaliamos os critérios

de riscos, com: análise financeira, análise de capacitação dos recursos,

certificações, consulta a clientes do fornecedor, etc., que são necessários em um

bom processo de sourcing.

A Gestão de Riscos de Fornecedores também é utilizada durante o projeto, quando

verificamos o processo de acompanhamento e qualificação que inspecione a

capacidade e avalie o risco do mesmo fornecedor atender a vários projetos

simultâneos da empresa.

Na Gestão de Programas, avaliamos se existem projetos concorrentes e como eles

disputam os recursos da empresa entre si, como são monitorados e como são

resolvidos conflitos. Também verificamos se as lições aprendidas em um projeto

são utilizadas nos demais, como os gerentes de projeto se comunicam entre si, e o

quanto conhecem dos outros projetos e dos programas.

Governança para Gestão de Resultados

Começamos avaliando como a empresa definiu os objetivos e benefícios para o

projeto, como foram aprovados e documentados, e quais os critérios de sucesso

foram estabelecidos para “medir” o desempenho do projeto.

O valor ou benefício do projeto pode mudar durante o projeto, isso ocorre porque

durante o seu desenvolvimento o mercado muda e a empresa muda, portanto

alguns benefícios podem ser ampliados e outros reduzidos. Além disso, novas

demandas ocorrem nesse período, e os ajustes de escopo podem ou não ser

WHITE PAPER


7

aprovados. Quando avaliamos a Gestão do Valor, estamos identificando como a

empresa avalia os impactos e aprova ou rejeita as mudanças de escopo a fim de

maximizar o valor ou benefício do projeto.

A Gestão do plano operacional está muito ligada aos processos de negócio. Todo

projeto tem impacto sobre pessoas, tecnologia e processos, em um projeto de

sistemas, por exemplo, o projeto gerencia a mudança em tecnologia, e cabe à

empresa se preparar para operar de forma diferente seus processos. Aqui

avaliamos se os ajustes em processos estão planejados e sua execução está sendo

gerenciada para sincronizar com a finalização do projeto.

Quanto ao Controle da Complexidade, aplicamos tanto no período de concepção

do projeto como nos momentos de ajustes de escopo. Avaliamos se a

complexidade foi avaliada e segregada a fim de reduzir os riscos do projeto.

Temas recorrentes são: abrangência regional, nacional e internacional; variedade

de culturas, legislação local versus solução global; as variedades de língua dos

usuários; a comunicação com outros sistemas; e outras. A questão não é medir a

complexidade, mas avaliar como ela é gerenciada, em quais fóruns e com a

participação de representantes de todas as áreas envolvidas, a fim de evitar a

super-simplificação que pode levar a um escopo reduzido e ineficaz ou à super-

complexidade que leva a um projeto maior que a capacidade da equipe.

Gestão do Projeto quanto a prazo e orçamento

Avaliamos o planejamento de atividades do projeto. Foram usados critérios

compatíveis com a complexidade do projeto? O re-planejamento ocorre com

freqüência de modo a acomodar as mudanças que ocorrem durante o projeto? O

pessoal tem experiência adequada para o planejamento? Os números fazem

sentido? Projetos similares foram utilizados para comparação? Existe caminho

crítico? Os problemas podem ser antecipados pela equipe e eles sabem o que fazer

se as coisas derem errado? Partimos do pressuposto que a equipe tem capacitação

WHITE PAPER


8

necessária para executar o projeto, portanto a Verificação Independente não deve

auditar documentos, mas deve avaliar o nível de segurança das pessoas que

geraram esses documentos e controles do projeto.

Gestão dos contratos se refere aos termos que estão contratados e como são

gerenciados. Por exemplo, se o fornecedor tem penalidade por atraso na entrega;

como foram especificadas essas entregas; quais são as possibilidades de troca de

fornecedor se necessário; a propriedade intelectual; o sigilo; etc. Note que em

Governança avaliamos como foram selecionados os fornecedores do projeto, já

aqui, avaliamos quais cláusulas e cuidados existem especificamente para o projeto

em análise.

Em seguida avaliamos a gestão do serviço entregue pelo fornecedor. Quais são os

níveis de serviço (SLA) pactuados, como são medidos e verificados e como são

feitos os aceites. Verificamos como o projeto está capacitado para gerenciar o

fornecedor, e como o fornecedor está respondendo às demandas do projeto.

O conhecimento gerado no projeto deve ser documentado adequadamente, nesse

ponto a Verificação Independente analisa como é documentado o conhecimento e

como é compartilhado com o restante da empresa, em especial quanto a conceitos

e regras de negócio. Em caso de rotatividade da equipe, a documentação é

suficiente e ao seu final, está em nível adequado para a manutenção do

sistema/solução desenvolvida? Associado ao conhecimento vem a metodologia

para desenvolvimento, em especial se o método é apropriado para aquela

tecnologia e complexidade do projeto, e se é de fácil assimilação nos casos de

alta rotatividade da equipe.

A gestão de um projeto é fundamentalmente dependente da gestão de pessoas.

Um projeto é, normalmente, um processo não repetido, ou seja, cada projeto é

único e depende do poder inventivo das pessoas. Devemos, portanto, avaliar se o

pessoal empregado no projeto tem as características pessoais de inventividade,

WHITE PAPER


9

experiência e conhecimento do negócio e da tecnologia. Sempre será uma

avaliação subjetiva, mas podemos avaliar principalmente: anos de experiência na

empresa, tempo de experiência na tecnologia, capacidade de liderança individual,

facilidade de expressão, nível de conhecimento dos eventos das demais frentes de

projeto (integração das pessoas), nível de entendimento do projeto,

conhecimento dos milestones do projeto, como os subordinados reconhecem a

liderança do gerente, etc. Esses são fatores que o gerente de projeto pode não

perceber, porque a maneira como sua equipe se relaciona com o líder pode alterar

a percepção que o líder tem da sua equipe. Nessa análise o principal beneficiado

será o gerente de projeto que poderá atuar para melhorar sua liderança e auto-

conhecimento.

Controle de custos e orçamento. Encontramos em vários de nossos clientes um

traço comum de confundir controles de despesas e controle do orçamento. O

primeiro – despesas – se refere à avaliar uma despesa antes de executá-la,

comprar bem, gastar pouco, etc., e isso a maioria dos clientes faz muito bem. Já

o controle do orçamento significa ter a autonomia para gastar mais naquilo que é

importante e gastar menos, naquilo que pode ser cortado. Na análise da gestão de

custos, devemos prestar atenção à capacidade do projeto em tomar as decisões

difíceis quanto ao orçamento, porque ás vezes é preciso gastar mais para poder

entregar a qualidade dentro do prazo. Avaliamos, portanto, como o gerente de

projetos toma decisões, quais controles utiliza, seus critérios, sua dificuldade para

aprovar despesas e a real autonomia que tem.

A escola de gestão de projetos nos ensina a congelar o escopo. Mas o escopo seria

fixo se fosse perfeito, definido por meio de um planejamento perfeito, sem

estimativas, porque estimativas não são perfeitas por definição. Na prática não

existe escopo que não precise ser alterado durante o projeto. Todas as principais

variáveis de projeto mudam no tempo: o mercado, a demanda do cliente, a

solução da concorrência, os outros projetos da empresa, o perfil dos usuários, a

legislação, enfim, a pressão por mudança de escopo existe. O projeto que não

muda nada está tão errado quanto o projeto que muda tudo. A Verificação

WHITE PAPER


10

Independente deve avaliar como as decisões são tomadas, em qual esfera de

poder, com qual envolvimento dos clientes/usuários e em especial: com qual

análise de impactos e qual ajuste de orçamento e prazo. É uma análise da

capacidade para gerenciar escopo e não do escopo em si.

Gestão do Projeto e o Risco Operacional

A falta de qualidade introduz problemas na operação que só são percebidos depois

de terminado o projeto. Dividimos esse tema dois: projeto e produto do projeto. A

qualidade do projeto é entregar ao seu cliente aquilo que foi solicitado, mais as

alterações de escopo que foram gerenciadas durante o projeto. Nesse âmbito,

avaliamos o grau de envolvimento do cliente durante o projeto (nas regras de

negócio, na avaliação dos protótipos, na discussão de alternativas durante o

projeto, etc.) A documentação inicial deve incluir especificação funcional,

especificação técnica e protótipos e devemos conseguir identificar como se

atualiza essa documentação durante o projeto. Além desses cuidados, devemos

avaliar os procedimentos de homologação – como o cliente vai atestar que o que

está recebendo é aquilo que encomendou ao Projeto.

Já a qualidade do Produto do Projeto (código, no caso de sistemas) será medida

pelo número de falhas que apresente na operação. Devemos estar atentos a

quantas rotinas de teste foram executadas para conseguir aprovar o teste, quais

os procedimentos para a qualidade são empregados pelo fornecedor, qual o

histórico de outros projetos (o fornecedor está melhorando?) e, quando a

verificação ocorre no final (cut-over ou pós-implantação), qual é o histórico de

problemas observado na operação.

Todo projeto tem ajustes de tecnologia também, o que chamamos de Desvios de

Padrão. Em um projeto ERP pode ser entendido como “customização”. Em um

projeto de sistemas, pode ocorrer quando se adota uma tecnologia que não está

prevista nos padrões de arquitetura da empresa. De qualquer modo, avaliamos

WHITE PAPER


11

aqui, como são tomadas as decisões para evitar os desvios, como os desvios

inevitáveis são documentados e como se planeja a sua manutenção no futuro

(pessoas, custos, orçamento, suporte de fornecedores, etc.).

Administração da informação tem por objetivo identificar como o Projeto avalia as

informações que serão carregadas em um novo sistema. Cadastros, pedidos,

tabelas de preço, informações de clientes, dados confidenciais, etc., são alguns

dos exemplos aplicados. Esses dados têm que ser analisados e “limpos” antes de

estarem prontos para o novo sistema. A Verificação Independente vai procurar

quem são as pessoas com essa incumbência, como planejaram suas atividades e

como executam a preparação das informações que irão alimentar o novo sistema.

Administração de dados se refere ao cuidado em documentar a arquitetura de

dados, as interfaces e a taxonomia, planejando como os dados serão extraídos e

alimentados no novo sistema. Na Verificação Independente, avaliamos o

planejamento e execução da atividade, em especial, se a equipe “sabe o que está

fazendo”, se o planejamento é coerente e se está adequadamente integrado ao

planejamento do projeto.

Na análise dos testes e piloto, verificamos se a execução prevê os testes unitários

e os três ciclos de teste integrado: teste do código/ teste da lógica/ teste das

interfaces. Qual a qualidade dos dados para teste (dados reais?), qual a

organização de teste, qual o ambiente, preparação dos cenários de teste e demais

cuidados no planejamento e execução dos testes.

A prova de desempenho é avaliada quanto ao método e processo de avaliação:

volume de dados, teste de stress, teste de desempenho, critérios utilizados,

evidências geradas, prazo planejado e confiabilidade dos testes.

WHITE PAPER


12

Para a prova de usuário, avaliamos como o usuário é inserido nos testes e

homologação do sistema. Devemos conversar com os usuários e captar sua

percepção, se o sistema funciona, se atende às expectativas, como foi envolvido,

como avaliou os resultados, etc. Mais do que um simples ponto de checkagem, a

Verificação Independente pode antecipar ao gerente de projeto os problemas que

os usuários têm, mas que não são reconhecidos pelo Projeto e vão dar problema

na implantação.

A infra-estrutura para suporte do sistema deve ser adequada para atender aos

usuários e executar a manutenção corretiva futura. Em um projeto de construção

de um edifício, a construtora tem que formar o condomínio antes de entregar os

apartamentos. Da mesma forma, em um projeto de sistemas o help desk e a

manutenção devem ser planejados e organizados antes da entrega do projeto,

mas, em geral, o gerente de projeto não tem essa preocupação, porque a vê como

fora de sua responsabilidade, já que ocorre após a finalização do Projeto. A

Verificação Independente deve atestar se a empresa está pronta para receber o

produto do projeto, pois a verificação deve atender à empresa e não somente ao

gerente de projeto.

Avaliamos ainda como o projeto dá “garantia” daquilo que entregou, em especial,

se os fornecedores têm alguma obrigação em corrigir o sistema por um período

após a implantação, avaliamos qual é esse período e quais são suas

responsabilidades. Também avaliamos como ocorre a transferência do

conhecimento do projeto para a equipe de manutenção, e os procedimentos de

aceite e transferência da responsabilidade. Em alguns casos, existe a Operação

Assistida, um período em que o fornecedor e parte do projeto continuam à

disposição da empresa, operando a solução até que esta se estabilize. Nesse

período a Verificação Independente deve avaliar os indicadores de falhas e se há

ou não empenho dos envolvidos na estabilização (redução das falhas e curva

tendendo a zero).

WHITE PAPER


13

Gestão da mudança

Muito já se falou sobre gestão da mudança, mas na prática, é muitas vezes

negligenciada pela empresa. Por vezes a responsabilidade pela gestão de mudança

organizacional é delegada à mesma equipe de gestão de projeto, o que é um erro.

Para sua maior eficácia a gestão da mudança deve se reportar diretamente ao

sponsor do projeto ou ao RH da empresa, pois enquanto o projeto cuida da

tecnologia, a gestão da mudança deve cuidar das pessoas.

Primeiro avaliamos como o impacto na organização é documentado e quais ações

são tomadas para ajuste organizacional: contratação de pessoal, planejamento da

dispensa de pessoal, mudança no organograma, envolvimento das gerências, etc..

Ao final do projeto, a nova estrutura de suporte fará parte de qual organograma,

como as pessoas do projeto serão realocadas em seus departamentos, quem

retorna para onde e quem não continua, ou seja: há planejamento para isso

acontecer?

Avaliamos também o plano de comunicação interna, a “propaganda” do projeto, o

envolvimento de toda a empresa e como se faz para dissimular as “fofocas”

quanto aos impactos e mudanças organizacionais. Como se comunicam os

benefícios, qual a mensagem que percorre na empresa e como se planejam as

atividades de comunicação. Tratamos também do apoio ao treinamento dos

usuários, a logística e planejamento, os recursos, o convite e a estratégia para

garantir a participação de todos.

Verificamos como a equipe lida com o clima organizacional, quais são as

atividades do dia-a-dia para manter a equipe de projeto motivada, e as atividades

para envolver os usuários que são part-time do projeto. A remuneração dos

recursos de projeto, premiações e reconhecimento do sponsor quanto ao trabalho

da equipe, são também temas da Verificação Independente.

WHITE PAPER


14

Os impactos que o projeto provoca na empresa podem demandar ações em outras

áreas da empresa. Um ERP, por exemplo, que provoca mudanças no recebimento

de materiais; ou a Nota Fiscal eletrônica que provoca mudanças na expedição. Na

Verificação Independente, entrevistamos as gerências das áreas impactadas, para

verificar como estão planejamento e se ajustando para receber o resultado do

projeto.

A Gestão do Risco do Projeto

Como vemos, a Verificação Independente é extensa e pode ser profunda, e por

isso, o programa de verificação deve ser escalonado no tempo, alinhado ao

cronograma de execução do projeto. Em cada evento de verificação é avaliado um

grupo diferente de fatores. Para projetos longos a freqüência pode ser mensal ou

bimestral.

Todos os fatores listados são potenciais riscos para o projeto se forem

negligenciados. Na TGT Consult utilizamos há alguns anos os critérios descritos

para criar uma Análise de Risco do projeto. A avaliação de cada item se

transforma em uma nota, e para cada grupo aplicamos um peso, dependendo do

escopo e complexidade do projeto, e a nota final ponderada nos produz um

indicador de risco de acompanhamento do projeto. Empregamos recentemente

essa metodologia na Fiat Automóveis e Petrobras, em projetos complexos de longa

duração.

WHITE PAPER


15

Conclusão

O papel principal da Verificação Independente é trazer para o gerente de projeto

as informações que não chegam a ele pelos caminhos naturais, e aquelas que

passam despercebidas, por estarem fora do turbilhão de problemas do dia-a-dia.

Para o sponsor, é uma ferramenta importante para receber, de forma simplificada

e resumida, o que está bom e o que está ruim, e um guia para ele saber onde deve

atuar para remover obstáculos, não só no âmbito de projeto, mas principalmente

no lado externo do projeto: a empresa, os fornecedores e clientes. Quanto a isso,

o gerente de projeto também é beneficiado, pois a Verificação Independente o

ajuda a resolver problemas externos ao projeto, nos casos em que ele, sozinho,

não conseguiria “mover” a empresa.

Elaborado pela TGT Consult. © 2009

Contatos: [email protected]

verificação independente

Documents