Considerações sobre a EAP & Exemplos aplicados

Transcrição

1 Considerações sobre a EAP & Exemplos aplicados (Peter Mello, peter.mello@x25.com.br) A EAP Estrutura Analítica de Projetos (ou WBS) é um dos elementos essenciais do Gerenciamento de Projetos. A partir do levantamento de perguntas e respostas sobre o assunto encontradas na lista de discussão do Capítulo de São Paulo do PMI, este tema então foi estendido com a aplicação de algumas noções úteis à sua aplicação prática com o Spider Project. O Spider Project Desk200 é uma ferramenta de distribuição gratuita, disponível para aplicação profissional em projetos de pequeno porte. Ela permite a criação de EAPs com um número ilimitado de níveis e pacotes de trabalho e sua elaboração através de recursos de árvore, hierárquico ou com a aplicação do Diagrama de Gantt. Assim, para o contexto de aplicação da Estrutura Analítica de Projetos a Desk200 é 100% funcional e 100% gratuita. O passo seguinte após a montagem de uma EAP de projeto é a constituição do Cronograma de Projeto. Para este caso, a versão DESK200 é limitada a um conjunto de 200 atividades, suficiente para projetos de pequeno porte. Parte das considerações feitas neste documento está baseada no conteúdo encaminhado por Danilo GENARE Denis, Membro do Conselho de Orientação do PMI-SP, em publicado na lista em 05/06/2009. Os trechos retirados deste estão sinalizados em azul e itálico, com o nome do autor [GENARE]. Parte 1 Criar Estrutura Analítica de Projeto (PMBOK ) O Processo 5.3 Criar Estrutura Analítica do Projeto é um dos primeiros processos que enxergamos no grupo de processos de planejamento no PMBOK. Ele necessita explicitamente da Declaração de Escopo do Projeto que é desenvolvida pelo processo 5.2 Definir Escopo e este, por sua vez, necessita explicitamente da documentação de requisitos desenvolvida pelo processo 5.1 Coletar Requisitos.

2 O conjunto de entradas, ferramentas e saídas destes três processos de escopo fundamentais para o desenvolvimento da EAP podem ser vistos a seguir: A EAP é então desenvolvida através da decomposição sucessiva do escopo do projeto e a principal fonte de informações para o detalhamento desta decomposição pode ser encontrado no Practice Standard of WBS Second Edition, outra publicação do PMI disponível para seus associados. Parte 2 Interação entre a EAP e a definição de atividades Sabemos que projetos têm uma característica de progressividade. Isso significa que na medida em que vamos evoluindo com seu planejamento e execução, vamos ampliando a visibilidade sobre seus objetivos e necessidades e, portanto é comum que o Plano de Projeto sofra constantes revisões. Após a elaboração da EAP, nós então iniciamos a definição de atividades, sequenciamento, estimativas de recursos e duração até chegarmos à elaboração de nosso cronograma. É comum que exista uma relação cíclica com a criação da EAP de tal forma que ela irá apoiar a definição de atividades e esta irá provocar a revisão da própria EAP. Esta elaboração cíclica e progressiva não pode ser mantida por toda a vida do projeto, pois é crucial que se estabeleçam as linhas de base do projeto, entre elas a linha de base do escopo, linha de base do cronograma e a linha de base de custos. Em um determinado momento que deve estar definido no Plano de Projeto e entre os objetivos do projeto, a EAP é então congelada (com a fixação da linha

3 de base) e futuras alterações deverão passar por um sistema de controle de mudança que permita ver a adequabilidade da mudança aos objetivos do projeto, os impactos sobre tempo, custo, uso de recursos, riscos, qualidade, entre outros. Os processos correspondentes ao Gerenciamento do Tempo no Grupo de Processos de Planejamento, com base ao PMBOK, são: Nota: Estes processos foram desenhados com o uso do InteliFrame e fazem parte do aplicativo InteliMedia e da instalação do Spider Desk200. Todo este pacote é gratuito e pode ser baixado em

4 Parte 3 Informações adicionais sobre a EAP/WBS com base aos tópicos discutidos na lista de discussão do PMI-SP WBS Work Breakdown Structure (Estrutura Analítica do Projeto) O objetivo de uma WBS é identificar elementos terminais (os itens reais a serem feitos em um projeto ) Em Gerência de projetos, uma Estrutura Analítica de Projetos (EAP), do Inglês, Work breakdown structure (WBS) é uma ferramenta de decomposição do trabalho do projeto em partes manejáveis. É estrutura em árvore exaustiva, hierárquica (de mais geral para mais específica) de entregáveis (deliverables) e tarefas que precisam ser feitas para completar um projeto. A WBS não é criada apenas para o gerente do projeto, mas para toda a equipe de execução do projeto. Uma WBS é uma representação gráfica e detalhada do Escopo do Projeto. É o agrupamento de produtos que organiza a definição total do produto do projeto denominada ESCOPO. O Trabalho que NÃO ESTÁ descrito na WBS NÃO DEVE ser feito. [GENARE] No Spider Project, uma WBS (EAP/Estrutura Analítica de Projeto) pode ser desenvolvida através de diferentes mecanismos: 1) Visão WBS convencional. Estrutura em formato de Árvore.

5 Os detalhes de cada componente da EAP podem ser customizados pelo usuário através da criação de um modelo. Assim, é possível enxergar a EAP com elementos relacionados ao cronograma, como data de início, fim, duração e folga; ou pode ser vista por elementos de custo como, por exemplo, o valor total do pacote, impostos, custo fixo, direto, indireto, etc. O usuário tem a flexibilidade de criar campos particulares, baseados na necessidade da própria organização. Como por exemplo: Status, Grau de Risco, Área Responsável, Código do Produto, Nível de Dificuldade, Quantidade de Materiais, Contagem de Pontos de Função, etc. 2) Outra forma de ver a mesma EAP é com o uso de estruturas hierárquicas. Elas são mais úteis em projetos com grande quantidade de fases e pacotes de trabalho, pois expressam a mesma informação em um espaço menor.

6 3) Um dos mecanismos de maior produtividade para a construção e manutenção de grandes EAPs e com isso estabelecer maior controle sobre os projetos é o de construção dinâmica de EAP. Uma EAP dinâmica é aquela construída a partir de características atribuídas às atividades que a compõem. Isso permite, por exemplo, que grande quantidade de atividades detalhadas em sistemas terceiros possam ser trazidas pelo software e incorporados à EAP principal de um projeto. Exemplo: Parte do projeto é realizada por um conjunto de operações. Estas operações são desenhadas pela equipe de Engenharia, descritas pelo pessoal de operação em um sistema ERP e então levadas para o Spider. Assim, cada peça que será produzida é descrita por um conjunto de operações, com suas respectivas características particulares. Uma peça então é descrita por um código do projeto, um código da peça e cada uma das operações necessárias, com a respectiva máquina. Algo como: OPA01 Corte de Chapa Equipamento A Peca01 Projeto 01 OPA02 Solda Equipamento Y Peca01 Projeto 01 OPA03 Acabamento Equipamento Z Peca01 Projeto 01 OPB01 Corte de Chapa Equipamento A Peca02 Projeto 01 OPB02 Solda Equipamento Y Peca02 Projeto 01 OPB03 Acabamento Equipamento Z Peca02 Projeto 01 Em uma carga inicial no Spider, estas operações viriam apenas como atividades seqüenciadas. No momento seguinte, através de instruções automáticas para o software (scripts) ou manualmente com a interferência do Gerente de Projetos, estas atividades são organizadas em visões diferentes. 3.1 Visão das atividades sem distribuição em uma EAP

7 3.2 Visão das atividades em uma EAP organizada por PEÇA 3.3 Visão das atividades em uma EAP organizada por EQUIPAMENTO Nota: As EAPs deste exemplo já estão inseridas no contexto de um cronograma e portanto as atividades que compõem cada pacote também estão presentes.

8 3.4 EAP organizada por EQUIPAMENTO & PEÇA Construir uma WBS (Work Breakdown Structure) é uma técnica fundamental no planejamento de um projeto e servirá de base para o detalhamento do escopo, não escopo, bem como a definição do cronograma, da matriz de responsabilidades, da avaliação de riscos e dos demais processos que integram o gerenciamento de projetos. A WBS tem como objetivo apresentar de forma gráfica (como organograma Forma de uma árvore ) ou como tabela (Lista identada), a Estrutura Analítica do Projeto, identificando as macro-atividades ou frentes de trabalho a serem desenvolvidas na condução do projeto. Cada uma dessas frentes, quando aplicável, esta deve ser detalhada até um nível que possibilite o adequado acompanhamento e controle do projeto ( cada atividade deverá ser detalhada em tarefas com as respectivas durações e datas de execução / conclusão ). [GENARE] A EAP deve então ser orientada a um estilo específico, durante a decomposição inicial. Ela pode ser orientada a Processo, ao Produto, ao Produto dentro do Ciclo de Vida, por região geográfica, entre outros. O Practice Standard of Work Breakdown Structure do PMI estabelece como boa prática a decomposição por Produto, ou Entregas. Com a aplicação de EAP dinâmicas no SPIDER é possível que a equipe inicie o seu trabalho com um estilo de decomposição, baseado em Entregas, e durante o seu detalhamento realize parte da decomposição seguindo outro estilo, como prioridade, grau de risco, área funcional responsável, entre outros. Após o fechamento de uma EAP abrangente o próximo passo é a definição de atividades que compõem cada pacote e então, através dos atributos de cada atividade podemos reconstruir dinamicamente a EAP para diferentes formatos. - Ao entregar o cronograma para o cliente: Visão por Entregas - Ao entregar o cronograma para áreas funcionais: Visão por Responsabilidade - Ao entregar o cronograma à área financeira: Visão por Centros de Custo - Etc.

9 Qual o nível de detalhe de um WBS? Quanto mais detalhado... Mais informações teremos sobre o projeto; Maior precisão teremos sobre o prazo de término; Mais tempo gastaremos no plano; Mais tempo será gasto no acompanhamento; [GENARE] Na medida em que ampliamos o nível de detalhamento de nosso projeto, nós ampliamos nossa visibilidade em relação aos riscos, custos, materiais necessários, entre outros. Mas existe um preço a pagar em relação a planejamentos detalhados no momento de efetuarmos o controle de avanço do projeto. Em suma, o nível de detalhe imposto ao planejamento de um projeto deve ser proporcional à capacidade de controlar o seu andamento. Um recurso extremamente interessante no Spider Project Professional é criado com o uso de hammocks (detalhado em item posterior). Hammocks permite que partes detalhadas em diversos pacotes de trabalho sejam de fato re-integradas em uma única visão gerencial, facilitando o controle. O Gerente de Projeto só precisa se ater ao detalhe de controle se no nível superior de seu controle, com a hammock, algum desvio for identificado. Assim, para o Gerente de Projeto, os pacotes de trabalho são virtuais, resultantes do conjunto de atividades que estão em um nível que ele não irá acompanhar no dia-a-dia. Em caso de DESVIOS em relação ao planejado, então o Gerente de Projeto pode optar por examinar em detalhe os itens que formam aquele pacote de trabalho, independentemente da EAP que foi desenvolvida nos níveis mais baixos.

10 Percebe-se neste caso que uma hammock é um tipo especial de atividade cuja duração é calculada com base a um conjunto de atividades distribuídas em diferentes pacotes de trabalho. Ela torna-se então um pacote de trabalho virtual e dá visibilidade ao GP e ao cliente de Entregas de projeto, mesmo que a organização das demais atividades esteja distribuída em EAPs híbridas, por fase, área funcional, departamento, prioridade, responsabilidade, centro de custo, etc. Na ilustração acima, o detalhe de cada hammock está baseado na EAP construída por TIPO DE EQUIPAMENTO (A, Y, Z) e na ilustração abaixo a mesma hammock está baseada na PEÇA (01, 02). O Que são Work packages? ( pacotes de Trabalho ): São as atividades concretas onde são efetivamente alocados os recursos. Consideradas as unidades de contabilização do projeto que podem ser associadas a entradas do plano de contas. Como em um plano de projeto em miniatura, um pacote de trabalho ou work package é um subconjunto de um projeto que pode ser designado para uma parte especifica da execução. Devido a esta similaridade, pacotes de trabalho são frequentemente confundidos com projetos. Similar a uma WBS, um pacote de trabalho é parte de uma Estrutura analítica do produto, representando um coleção de trabalhos necessário para criar um resultado específico. O Pacote de trabalho é definido por breves enunciados de: Descrição das atividades Atividades dos recursos por habilidade. Programação de atividades, Riscos das atividades. Ornamentação das atividades. Os pacotes de trabalho são designados por uma autorização de trabalho ou liberação de controle. [Genare] Uma vez que um determinado pacote de trabalho pode de fato ser decomposto em novos pacotes e estes terem suas atividades necessárias a sua execução

11 definidas, no Spider Project podemos criar uma biblioteca de fragmentos de projeto (fragnets) que são especializados na execução de um determinado tipo de pacote de trabalho. Um Pacote de Trabalho pré-definido pode ser: - Instalação Elétrica para um andar de um prédio; - Construção de 1 km de Gasoduto; - Desenvolvimento e Testes de um Caso de Uso; - etc. Isso permite, por exemplo, que projetos sejam desenvolvidos mais rapidamente e por pessoal com menor grau de especialidade, de forma mais consistente. Assim, quando uma equipe de vendas estabelece um cronograma preliminar de um projeto, diversos elementos deste cronograma preliminar podem ser provenientes de informações reais e consolidadas de projetos anteriores, aumentando o grau de assertividade nas estimativas e orçamentos. Ao desenvolver um Pacote de Trabalho detalhado para a realização da instalação elétrica de um andar de um prédio, com um determinado padrão de qualidade e metragem, este mesmo pacote de trabalho pode ser reaproveitado para a orçamentação não só dos demais andares daquele prédio, mas também ser escalonado para uso em outras situações. Dentro de um pacote de trabalho, podemos identificar itens escalonáveis que nos permitem ampliar a capacidade de adequação de um pacote de trabalho de um projeto aos projetos futuros. Itens determinados por volumes e produtividades podem então rapidamente ser aplicados em novos projetos onde a identificação dos novos volumes de trabalho irá assistir ao Gerente e Equipe em relação às estimativas de tamanho de equipe, quantidade de materiais necessários, custos, prazos, etc. Como construir uma WBS? Processo de criação Requer julgamento, experiência, avaliação de alternativas e iteração. Para cada componente da WBS deve-se usar o conceito CONSUMIDOR / FORNECEDOR, ou seja, o que será produzido será consumido, ou terá alguma utilidade? O Principal requisitos para a construção da WBS é orientar o raciocínio do construtor para adoção de um dos estilos ( Produto, Processo ou Híbrido ). É aconselhável a utilização do PENSAMENTO INVERSO, ou seja, Pensar ao contrário. Para quebrar este paradigma deve-se visualizar o produto do projeto, e fazer a seguinte pergunta...: Para que o (PRODUTO) seja construído, eu necessito (Ação ) A resposta será um componente da WBS.

12 Um dos mais importantes princípios para o projeto de uma WBS é conhecido como a regra dos 100%. O Practice Standard for Work Breakdown Structures (Second Edition), publicado pelo Project Management Institute (PMI) define a regra 100% da forma como se segue: A Regra 100%... estabelece que a WBS incluem 100% do trabalho definido pelo escopo do projeto e captura todas as entregas internas, externas, intermediarias de forma ao trabalho estar completo, incluído o gerenciamento do projeto. A regra dos 100% é um dos mais importantes princípios que guia o desenvolvimento, decomposição e avaliação da WBS. A aplicação desta regra vale todos os níveis na hierarquia: a soma de todos o trabalho dos níveis "filhos" de ser igual a 100% do trabalho representado pelo "pai" e a WBS não deve incluir qualquer trabalho que saia do escopo existente do projeto, isto é, ele não pode incluir mais do que 100% do trabalho... É importante lembrar-se que a regra do 100% também se aplica ao nível de atividades. O trabalho representado pelas atividades de cada pacote deve produzir 100 % do trabalho necessário para completar o trabalho do pacote. ATENÇÃO!!!!! Planeje as entregas, evite planejar as ações Se o projetista da WBS tenta a capturar qualquer detalhe orientado a ação na WBS, ele ira incluir ou ações de mais ou de menos. Ações demais ira exceder 100% do escopo do pai e ações de menos ira cair abaixo dos 100% do escopo do pai. A melhor forma de ser aderente a Regra do 100% é definir os elementos da WBS em termos das entregas ou resultados. Isto também assegura que a WBS não exagere na visão dos métodos, permitindo idéias mais criativas e inovadoras por parte dos participantes do projeto. Para projeto de desenvolvimento de novos produtos, a técnica mais comum para assegurar a orientação para a saída da WBS é o uso de uma estrutura de quebra do produto. Desenvolvimento orientado aspectos utiliza-se de uma técnica similar qual é emprega uma estrutura de decomposição de aspectos. Quando um projeto prove serviços profissionais, uma técnica comum é capturar todos as entregas planejadas para criar uma WBS orientada a entrega. WBS que subdividem o trabalho em fases do projeto (por exemplo: Fase Projeto Preliminar, Fase projeto Critico) devem assegurar que as fases sejam claramente separadas para uma entrega (por exemplo: um documento de revisão de projeto preliminar, ou um documento aprovação da revisão projeto critico) Nível de detalhe (granularidade) e elaboração progressiva Uma questão a ser respondida no projeto de qualquer WBS é quando parar de quebrá-la em elementos menores. Se os elementos finais da WBS são definidos de forma muito abrangente, não deve ser possível rastrear eficientemente a performance do projeto. Se os elementos finais da WBS são muito detalhados, será ineficiente manter um rastreamento de um numero exagerado de elementos terminais, especialmente se o plano de trabalho é para um futuro distante. Um meio termo satisfatório pode ser encontrado no

13 conceito de elaboração progressiva o qual permite que os detalhes da WBS seja progressivamente refinado antes trabalho ser iniciado. Uma forma de elaboração progressiva em grandes projetos é chamada de planejamento ondas girantes o qual estabelece um planejamento de tempo regular para elaboração progressiva. Na realidade, um limite efetivo da granularidade da WBS pode ser alcançado quando ela não é maior do que é possível para se gerar saídas planejáveis, e os únicos detalhes remanescentes são as ações. A não ser que estas ações possam se definidas para aderir a regra dos 100%, a WBS não pode ser mais subdividida. Esquema para codificação WBS É comum para elementos WBS serem numerados sequencialmente para revelar a estrutura hierárquica. Por exemplo Pneu Traseiro identifica este item como o 3 elemento da WBS, desde que existe o numero 3 separado um ponto decimal. Um esquema de codificação também ajuda os elementos WBS serem reconhecidos em qualquer contexto escrito. Métodos a serem utilizados Entende-se por Método a seqüência lógica de procedimentos ou operações para se realizar determinada tarefa ou atingir determinado objetivo. Neste caso em particular, os métodos que podem ser adotados para a definição de uma WBS são: Heurísticas = Refinamentos sucessivos, ou seja, do geral para o particular Uma regra, simplificação, ou aproximação que reduz ou limita a busca por soluções em domínios que são difíceis e pouco compreendidos. Deste modo para um problema que não se conhece qual é o melhor caminho em busca de uma solução, define-se uma função heurística que acredita-se levara a esta solução. Rolling wave = Como uma onda que segue para frente no tempo. Refletem a evolução do escopo do projeto conforme ele se torna mais detalhado, até chegar ao nível de pacote de trabalho. O planejamento em ondas sucessivas é uma forma de planejamento de elaboração progressiva em que o trabalho que será realizado á curto prazo é planejado em detalhes em um nível baixo da EAP, enquanto o trabalho distante no futuro é planejado para os componentes da EAP que estão em um nível relativamente alto da EAP. O trabalho a ser realizado dentro de um ou dois períodos de relatório no futuro próximo é planejado em detalhes conforme o trabalho está sendo terminado durante o período atual. Portanto, as atividades do cronograma podem existir em vários níveis de detalhes no ciclo de vida do projeto. Durante o planejamento estratégico inicial, quando as informações estão menos definidas, as atividades podem ser mantidas no nível de marcos.

14 Forma da decomposição 1-)Identificar os componentes mais importantes do projeto. 2-)Para cada componente: se estimativas adequadas de custo e duração podem ser feitas nesta etapa então vá para 4 senão vá para 3. 3-)Identifique os elementos tangíveis constituintes deste componente. Repita o passo 2 para cada elemento. 4-)Verifique a correção da decomposição. Tarefas de suporte Não esquecer das tarefas de suporte. Muitas tarefas do WBS não são diretamente ligadas ao produto principal como a gerência do projeto, demonstrações, entrega do produto, más são considerados produtos do projeto e necessários para que o projeto seja concluído. Como verificar uma WBS Processo de verificação da correção: 1- Os itens de nível mais baixo são necessários e suficientes para a conclusão do componente? 2- Cada um dos itens está completamente definido? Ao final do planejamento verificar para cada componente da WBS tem as seguintes definições de data, prazo, orçamento e responsável associado. WBS e Incerteza WBS determinista Representamos as tarefas que temos certeza que deverão ser efetuadas. No mundo real, isto raramente acontece. WBS não-determinista Representar aquelas tarefas que tem uma probabilidade de serem executadas. Exemplos: 1-O sistema entregue pode ser rejeitado pelo cliente, obrigando a uma certa quantidade de retrabalho. 2-O novo pacote é muito mais difícil de ser aprendido do que o esperado, obrigando os técnicos a fazerem um curso no exterior

15 EM RESUMO, Para facilitar a criação da WBS, responda as seguintes perguntas para cada item da WBS. - Quem faz o que? - Quando? - De que forma? - Com que Freqüência? - Quais são as dependências? ( Premissas e Restrições ) - Quais os Riscos envolvidos? - O que será feito para mitigar os riscos? [Genaro] No Spider Project, podemos trabalhar com o desenvolvimento de Cronogramas Probabilísticos. A sua aplicação pode significar, por exemplo, que um mesmo projeto tenha EAPs diferenciadas para cada cenário. Exemplo: Cenário Otimista: A EAP do projeto contém pacotes de trabalho para a entrega de software onde as atividades relacionadas à entrega de produtos desenvolvidos, testes e retrabalho são mínimas. Cenário Provável: A EAP contém atividades complementares em função de uma provável necessidade de um maior número de vezes de iterações entre desenvolvimento e testes até que a entrega em si seja completada. Cenário Pessimista: Pode considerar o aparecimento de problemas de projeto que precisam ser tratados como, por exemplo, um módulo do software cuja especialidade técnica não é de domínio da equipe e portanto um determinado pacote de trabalho será transferido para terceiros. A EAP do cliente pode permanecer inalterada, mas o pacote de trabalho correspondente à entrega pode ser derivado em outros pacotes que são então administrados junto aos terceiros. O desenvolvimento de cronogramas probabilísticos não é tratado neste documento. Informações adicionais podem ser encontradas em em todos os documentos que discutem a aplicação do SDPM Success Driven Project Management. O uso de cronogramas probabilísticos permite: A) Ampliação da margem de assertividade em projetos em datas e custos negociados com clientes; B) Ampliação do controle sobre os eventos de risco e incertezas; C) Cálculo de reservas de tempo e custo necessários para lidar com as incertezas e riscos; D) Análise de tendências de probabilidade de sucesso do projeto; E) Entre outros.

16 Conteúdos relacionados: - Fragnets, Gerenciamento de Riscos, Nivelamento de Recursos, Otimização de Cronogramas, Análise de Indicadores de Projeto, Gerenciamento por Tendências, Análise de Valor Agregado, CPM,CCPM, RCP, entre outros. Peter Mello detém as certificações do PMI : PMP e PMI- SP. Também é certificado como especialista em otimização e cronogramas pela Spider Management Technologies (SpS), consultor em Gerenciamento de Portfólios, Projetos e Riscos e membro ativo da comunidade de Gerenciamento de Projetos com dezenas de artigos publicados em seminários nacionais e internacionais.