Escopo e a síndrome do francês

Basicamente escopo define os grandes objetivos de um projeto. É de fato o conjunto de todos os produtos, serviços e resultados que devem ser fornecidos para que um projeto seja considerado bem sucedido. Não por acaso o gerenciamento de escopo concentra-se em definir o que está e o que não está incluído em um projeto.

Na prática, o escopo é a primeira atividade do planejamento realizado para um projeto. Essa definição servirá como espinha dorsal do projeto. Sem conhecer claramente quais são os objetivos a serem alcançados no projeto, não se pode estimar em quanto tempo o trabalho será executado e nem quanto esse trabalho irá custar.

Uma das grandes habilidades que um gerente de projetos precisa desenvolver é a capacidade de proteger o escopo. Projetos que freqüentemente mudam o escopo durante a sua execução têm serias dificuldades em cumprir o cronograma e os custos estabelecidos inicialmente. Esta ocorrência é chamada de “scope creep”, termo em inglês para o efeito de mudança lenta,  gradual e desordenada do escopo de um projeto, além dos objetivos planejados inicialmente.

Scope Creep é a síndrome do francês Jaque (e não é o professor Jacques Cousteau). É o Já que você está fazendo isso e já que você está fazendo aquilo e já que faremos isto.. e quando vemos a infinidade de Já Ques que aparecem o projeto já não tem mais salvação.

Toda vez que aceitamos essas pequenas melhorias não previstas, aceitamos passivamente a Lei de Porter: "O Gerente de Projetos sempre será solicitado a fazer cada vez mais, com cada vez menos , até que um dia seja necessário fazer tudo sem consumir nada".

Felizmente com um pouco de esforço e sete dicas é possível prevenir que o "mal do já que" mantenha-se longe dos projetos.
1) Defina o Escopo - É importante definir o que será entregue e o que não será entregue antes de iniciar qualquer trabalho em um projeto, bem como é necessário manter tais entregas intocáveis. É importante definir e defender a linha de base do escopo do projeto. A linha de base do escopo é o "slack line" do Gerente de Projeto. Escopo bem definido é a fortaleza do Gerente de Projeto.

2) Registre as mudanças e os seus impactos  - Embora o escopo bem definido seja nossa fortaleza, a única certeza da vida é que haverão mudanças. Pois bem faz-se necessário registrar tais mudanças e os impactos que tais mudanças irão acarretar no andamento do projeto. Essas mudanças devem ser validadas e aprovadas por um processo sistemático do Comitê de Controle de Mudanças.

3) Redefinir a Linha de Base - Uma vez que as alterações de escopo foram aprovadas, a condição de equilíbrio do projeto foi alterada. Portanto é hora de redefinir a linha de base do escopo.

4) Solicite Recursos Adicionais - Alterações de escopo sempre irão alterar a necessidade de algum tipo de recurso, sejam mais horas de implementação, sejam mais recursos humanos, sejam mais equipamentos ou sejam mais fundos. Escopo alterado requer alteração de recursos. Você não é mágico e nem santo para operar o milagre da multiplicação dos recursos.

5) Observe os sinais de que as coisas não estão nos trilhos - As más notícias sempre são dadas no último instante. O GP deve observar os sinais dados por sua equipe de projetos. Não se deixe enganar por reportes de que tudo está sempre indo muito bem.

6) Determine as Prioridades das mudanças solicitadas - Isto acontece quando várias partes interessadas solicitam diversas mudanças. O Comitê de Controle de Mudanças avaliar e priorizar quais as mudanças devem ou não ser implementadas.

7) Fuja das armadilhas "francesas" - Essas armadilhas se escondem em frases que se iniciam com nomes franceses. Já que, Enquanto, Assim que. Geralmente os franceses com esses nomes são lobos em pele de cordeiro. Apresentam uma solução simples para um problema, mas os estragos que são feitos no projeto são imensos.

A evolução do conceito de sucesso de um projeto.

Sucesso de um projeto é um dos conceitos que tem sofrido maior número de alterações ao longo dos anos. Inicialmente, o sucesso era medido em termos técnicos. Não havia a preocupação das organizações em definir o sucesso de um projeto em termos empresariais. O sucesso de um projeto baseava-se em  produtos adequados ou inadequados. Projeto de sucesso era aquele que o escopo era entregue não importando os prazos e os recursos empregados durante a sua execução.

A medida que a cultura de gerenciamento de projetos passou a ser disseminada nas organizações, a definição de sucesso passou a ser entendida como a conclusão de um objetivo no prazo, no custo e com a qualidade previamente acordados.

Essa definição, já mostra uma preocupação em atender alguns indicadores empresariais, porém é uma definição ainda incompleta. Projetos que são um sucesso em seu gerenciamento, com o seu escopo entregue no prazo, no custo e com a qualidade desejada podem tornar-se um grande fracasso de negócios, enquanto outros, com problemas de prazo, custo ou outros que tornam-se um sucesso para os negócios das empresas.

Um outro ponto de vista é definir o sucesso de um projeto a questões intangíveis, como por exemplo a aceitação do produto pelos stakeholders. Quem definirá se o projeto é um sucesso ou um fracasso são os stakeholders. A definição absoluta de sucesso de um projeto será visualizada quando um cliente estiver tão satisfeito com os resultados alcançados que permitirá a utilização de seu nome como referência.

Ambos pontos de vista estão corretos e ambos têm sua deficiência. O sucesso de um projeto deve balancear questões técnicas do gerenciamento do projeto e a percepção dos stakeholders.

Do ponto de vista dos stakeholders, o sucesso de um projeto deverá ser medido, dentre outros fatores, observando:

• Cumprir os objetivos
• Atender ao orçamento
• Concretização da qualidade
• Atender a conveniência e oportunidade da assinatura do contrato

Do ponto de vista do gerenciamento do projeto, o seu sucesso deverá ser medido, dentre outros fatores, observando:

• Utilização da metodologia de gestão de projetos;
• Estabelecimento de Processos de Controle
• Uso adequado de indicadores;
• Envolvimento do cliente;

Justificando um projeto através do Business Case

O Business Case é o documento que deve justificar o investimento no projeto com base nas estimativas de custo, prazo, e esforço contra riscos associados e benefícios que podem ser alcançados com o projeto. Este documento normalmente contém uma descrição das necessidades do negócio, bem como contém uma análise de custo-benefício  para justificar e estabelecer limites para o projeto.

O Business Case precisa suportar o projeto durante todo o seu ciclo de vida. Possibilitando em diferentes momentos avaliar sobre continuidade ou não do projeto. O Business case precisa apoiar a organização, validando se os objetivos e valor propostos pelo projeto continuam sendo válidos. Se a justificativa de negócio for válida no início do projeto, mas deixar de ser durante a execução, o projeto deve ser interrompido ou modificado.

Um Business Case de qualidade deve possuir uma justificativa consistente para o investimento, estar alinhado com os planos estratégicos da organização, identificar os benefícios, bem como identificar métodos para mensuração para os benefícios identificados. Além disso ele deverá responder alguns questionamentos, antes e durante o ciclo de vida do projeto, tais como:

• Vale a pena iniciar esse projeto?
• Por que estamos fazendo esse projeto?
• Vale a pena continuarmos com o projeto?
• Quais os efeitos colaterais com esse projeto?

Não existe uma estrutura fixa para um Business Case, porém ele deve contemplar pelo menos os  seguintes aspectos:

• Resumo Executivo;
• Descrição da Oportunidade;
• Recomendações;
• Análise de Risco;
• Avaliação Econômica-Financeira;
• Avaliação Técnica e Operacional;
• Avaliação Estratégica

Isto posto, conclui-se que o objetivo primário do Business Case é garantir que não se desperdice dinheiro implementando soluções sem um foco definido. É necessário descartar soluções que não agregam valor ao negócio das organizações.

Apesar da sua reconhecida importância para o negócio, muitas organizações não o fazem. Quais seriam os motivos? Pergunta complexa de difícil resposta. Não me arrisco a respondê-la para evitar qualquer juízo de valor, mas deixo esta reflexão como ponto de atenção para o sucesso de nossos projetos.

Planejar não é preciso!

Antes que me condenem pelo título deste post, informo que o adjetivo preciso, neste caso, refere-se a exatidão, certeza, definição. Na verdade, planejar um projeto é muito semelhante a preparar um plano de navegação para uma velejada. Conhecemos a marcação da raia, sabemos as posições das boias, sabemos quantas "pernas" haverão da regata, e conhecemos as condições iniciais do vento que permitem o melhor ajuste das velas. Mas e se o vento mudar de intensidade ou direção ao longo da regata? Nossos planos iniciais não servem mais para muita coisa e somos obrigados a adaptar.

Os processos de planejamento de um projeto levam ao estabelecimento de um conjunto coordenado de ações visando à consecução de seus objetivos. Nestes processos o escopo, os critérios de sucesso, e o trabalho a ser executado para o alcance dos objetivos são definidos e refinados, e são elaborados os planos de gerenciamento e os documentos que irão conduzir a execução desse trabalho, considerando que nossas premissas, variáveis multidimensionais minimamente conhecidas, irão ocorrer.

Em condições normais de temperatura e pressão nossos planejamentos seriam perfeitos. Porém nossas premissas não ocorrem exatamente da maneira que queremos? Estamos cercados por "e se"... Essa característica de incerteza de nossas premissas, torna o gerenciamento de projetos uma atividade igualmente incerta. À medida que as características e variáveis do projeto são entendidas é necessário revisitar os processos de planejamento e elaborar novos planos. É necessário realizar ajustes nos planejamento ao longo do projeto.

Planejar não é preciso. Não existem mágicas ou fórmulas matemáticas que transformem o planejamento em uma verdade absoluta. Nossa "velejada" está sujeita a mudanças repentinas nas condições do vento. Estamos falando de algo iterativo que deve ser progressivamente elaborado ao longo de todo ciclo de vida do projeto. A elaboração progressiva permite que a equipe de gerenciamento de projetos defina o trabalho e o gerencie com um maior nível de detalhes envolvidos no projeto.

Processos existem para serem.... revistos (conclusão)

A Norma ISO 21500, define que o gerenciamento de projetos exige coordenação significativa entre os processos de gerenciamento de projetos e, como tal, requer que cada processo usado esteja apropriadamente alinhado e conectado com outros processos. Alguns processos podem ser repetidos várias vezes durante o ciclo de vida do projeto para que os objetivos do projeto sejam atingidos.

De maneira geral, os processos de Gerenciamento de Projetos são tratados em vários treinamentos como elementos distintos e com as interfaces bem definidas. No dia a dia vemos que eles se sobrepõem e se interagem.

Os processos descritos no PMBOK, na Norma ISO 21500, ou nos manuais das diversas metodologias de Gerenciamento de Projetos reconhecidas, não precisam e nem devem ser aplicados uniformemente em todos os projetos ou em todas as suas fases.

A comunidade de Gerentes de Projetos reconhece que há mais de uma maneira de gerenciar um projeto, dependendo de fatores como os, o risco, o tamanho, o prazo, a experiência da equipe do projeto, a disponibilidade de recursos, a quantidade de informações históricas, a maturidade da organização em gerenciamento de projetos, bem como os requisitos da área de aplicação e da indústria.

Por este motivo, a equipe de Gerenciamento de Projetos deve perguntar-se constantemente se os processos aplicados são adequados à realidade. Executamos os processos para satisfazer nosso ego de Gerentes de Projeto ou por que a organização que nos contratou realmente precisa de que o processo seja executado dessa forma.

Portanto, convém que o gerente do projeto adapte os processos de gerenciamento para cada projeto, fase, organização ou cliente, para determinar quais processos são apropriados e o grau de rigor a ser aplicado. Os processos de gerenciamento que estão desalinhados aos propósitos a que eles servem, devem ser revistos.

Processos existem para serem ... revistos

De uma forma abrangente, processos são os instrumentos da implementação das estratégias da empresa, isto é, das ações que a empresa precisa tomar para aproveitar as oportunidades e evitar as ameaças identificadas no ambiente de negócios.

Dentre inúmeros conceitos para o termo “processo”, acredito que as melhores definições sejam:

Uma série de tarefas ou etapas que recebem insumos (materiais, informações, pessoas, máquinas, métodos) e geram produtos (produto físico, informação, serviço), usados para fins específicos, por seu receptor;

Uma introdução de insumos (entradas) num ambiente, formado por procedimentos, normas e regras, que, ao processarem os insumos, transformam-nos em resultados que serão enviados (saídas) aos clientes do processo;

Uma seqüência de tarefas e atividades utilizadas na entrada (input), que agrega determinado valor e gera uma saída (output) para um cliente específico interno ou externo, utilizando os recursos da organização para gerar resultados concretos.

ATENÇÃO: Procedimentos, Métodos de Produção e Processo são coisas diferentes! Os dois primeiros definem a técnica pela qual se produz algo, enquanto o último define a forma como esta técnica é empregada.

Um projeto é um conjunto único de processos que consiste em atividades coordenadas e controladas com datas de início e fim, empreendidas para atingir resultados únicos. Igualmente a quaisquer outros processos, os processos de Gerenciamento de Projeto devem estar alinhados aos objetivos estratégicos de cada organização.

Os processos usados em projetos são geralmente categorizados em três principais tipos:

Processos de gerenciamento de projeto, os quais são específicos para gerenciamento de projeto e para determinar como as atividades selecionadas ao projeto são gerenciadas;

Processos de entrega, os quais não são exclusivos para gerenciamento de projetos, que resultam na especificação e fornecimento de um produto, serviço ou resultado específicos e que variam dependendo da entrega específica do projeto;

Processos de apoio, os quais não são exclusivos para gerenciamento de projeto e que fornecem apoio pertinente e valioso para produtos e processos de gerenciamento de projetos em disciplinas como logística, finanças, contabilidade e segurança.

Aliás, é importante ressaltar que os processos de Gerenciamento de Projetos, possuem as mesmas características que quaisquer outros processos empresariais, ou seja:

Todos os processos têm entradas, saídas, clientes e fornecedores;

Todos os processos têm múltiplas etapas, tarefas, operações ou funções executadas em sequência ou simultaneamente;

Geram um resultado ou produto identificável, que pode ser um produto físico, um relatório, dados/informações verbais, escritos ou eletrônicos, um serviço ou qualquer produto final identificável de uma série de etapas;

O resultado / produto tem um receptor identificável, que define sua finalidade, suas características e seu valor, seja esse receptor um cliente externo ou interno;

Podem ser de natureza interna (quando têm início, são executados e terminam dentro da mesma empresa) e externa (quando têm início dentro da empresa, são executados e terminam fora da empresa);

Possuem interfuncionalidade, quero dizer, a maioria dos processos de GP atravessa os seus próprios limites, os limites do grupo de processo e de suas áreas de conhecimento em que ele se encontra, servindo de insumos para outros processos de outros processos, grupo de processos e área de conhecimento.

Dentre os fatores de sucesso de um projeto está a seleção apropriada dos processos de cada organização necessários para atingir os objetivos propostos. Dessa forma, a partir do momento em que os processos de gerenciamento de projeto assumem um papel meramente burocrático, existe a necessidade de revê-los.

Continua na próxima postagem....

Informações do Projeto / Dados do Projeto / Relatórios de Projeto

Imagine-se na cabine de comando de um avião 747 ou de um A380. Imagine-se cercado por um painel com várias luzes acesas, outras apagadas e algumas piscando de forma frenética. Em condições normais de temperatura e pressão, eu não faria a menor ideia do que isto significa, mas mãos de uma tripulação bem preparada, eu me sentiria bem confortável e aproveitaria a viagem, que acredito ocorreria sem grandes sustos. Porém toda essa calma e confiança têm apenas uma razão: A tripulação transforma os dados dos diversos instrumentos em informações úteis para subsidiar as suas ações e decisões que, em última análise, mantém o avião voando.

Essa história é apenas iniciar uma reflexão sobre estes 02 confusos conceitos do PMBOK 5 - Dados de Projeto e Informações de Projeto. Conforme o PMBOK 5,  uma quantidade significativa de dados e informações são gerados, coletados, processados, analisados e distribuídos para a equipe de projeto e outras partes interessadas.

Existe uma diferença geral entre DADOS E INFORMAÇÕES de um projeto. A regra geral, que não é muito clara, mas que funciona é: Os DADOS são coletados nos diversos processos de EXECUÇÃO e são compartilhados pelos diversos membros da equipe de projeto. Estes DADOS devem ser analisados dentro de um contexto e processados para transforma-los em INFORMAÇÕES nos vários processos de CONTROLE.

O PMBOK entende que esta diferença é tênue e que as expressões DADOS DE PROJETO e INFORMAÇÕES DE PROJETO podem causar certa confusão. Para minimizar esta confusão, o PMBOK propõe as seguintes 03 diretrizes para diferenciar estes conceitos:

Work Performance Data – Dados de Desempenho do Projeto – São as medidas primárias obtidas a partir dos processos de  Execução do trabalho do projeto. Exemplos destas medidas são o percentual de avanço físico completado, as datas de início e fim das atividades, custo atual, duração total, número de solicitações de mudança realizadas, etc...

Work Performance Information – Informações de Desempenho do Projeto – São as informações obtidas a partir dos processos de Monitoramento e Controle, analisadas no contexto geral e integradas, baseada nas relações entre as áreas. São exemplos dessas informações, o Status das entregas e as estimativas previstas para conclusão do trabalho do projeto, etc...

Work Performance Report – Relatórios de Desempenho do Projeto - A representação física ou eletrônica das Informações de Desempenho do Projeto, compilados em documentos do projeto, pretendendo-se gerar decisões ou levantar questões, ações ou sensibilização. São exemplos Relatórios de Status, Memorandos, Justificativas, Notas de Informações, Painéis de Controle do Projeto tipo “Dashboard”, recomendações, atualizações,etc...

Estes 03 conceitos, são melhor esclarecidos quando visualizamos o que o PMBOK chamou nesta 5ª edição de Fluxo de Dados, Informações e Relatórios do Projeto