PM2ALL - Gestão de Projetos

Estimar as durações das atividades do projeto consiste em prever o número de períodos de trabalho que serão necessários para, recorrendo a um conjunto especificado de recursos, terminar cada uma das atividades do projeto. 
Para estimar a duração de uma atividade (isto é para prever quanto tempo o trabalho deverá demorar a ser feito) necessitamos de usar dois métodos. O primeiro consiste em determinar o esforço necessário para realizar o trabalho, para depois podermos determinar a duração.

O que apresentamos a seguir é um exemplo prático da utilização conjunta da EAP / WBS Estrutura Analítica do Projeto orientada aos entregáveis, com a Estrutura Organizacional do Projeto EOP / OBS de forma a podermos criar a Matriz de Atribuição de Responsabilidades (MAR / RAM) que nos vai permitir um controlo mais eficiente da execução do projeto.

Começamos por criar da Estrutura Analítica do Projeto (EAP / WBS) orientada aos entregáveis do projeto (neste caso a construção de vivendas uni-familiares) e do respetivo Dicionário da EAP / WBS. Uma vez conhecidos os diversos Pacotes de Trabalho que são necessários para criar o produto do nosso projeto, estamos em condições de desenvolver a Estrutura Organizacional do Projeto (EOP / OBS). Conjugando estas duas estruturas hierarquicas é possivel criar a Matriz de Atribuição de Responsabilidades (MAR / RAM). 

Existem numerosas aplicações informáticas para suporte à gestão de projetos. Apesar de úteis, o software de suporte à gestão de projetos é, como o próprio nome indica, software de suporte e não software de gestão de projetos. Isto é, facilita determinadas atividades que de outra forma seriam excessivamente consumidoras de tempo, mas não se substitui ao gestor de projeto e ao conhecimento que este deve possuir das metodologias e dos processos de gestão de projetos.

Na nossa opinião, as organizações dão demasiada ênfase e confiam demasiado nas potencialidades do software de suporte à gestão de projetos, os quais são intensivamente usados, e por vezes de forma algo descuidada, durante a fase de planeamento e em particular para às atividades de calendarização do projeto.

Este processo envolve a determinação de quais os recursos (pessoas, equipamentos ou materiais) são necessários para a execução de cada uma das atividades do projeto, em que quantidade esses recursos são necessários, e quando necessitam estar disponíveis. Este processo deve ser coordenado em conjunto com o processo 7.1 Estimar os Custos do Projeto.

O Método do Diagrama de Precedências / Precedence Diagram Method (MDP/PDM) é um método de criação do diagrama de atividades de um projeto que usa caixas (também chamadas de nós) para identificar as atividades do projeto, e setas para identificar as relações entre as diversas atividades do projeto. Esta técnica é igualmente conhecida por atividade no nó (Activity on Node AON).

Sequenciar as atividades consiste em identificar e documentar as relações lógicas que existem entre as atividades identificadas no projeto. As atividades devem ser relacionadas entre si de uma forma lógica e tendo por base as interdependências decorrentes do trabalho a realizar em cada atividade.
Por exemplo, se estamos a construir uma casa, não podemos colocar as placas de cerâmica no piso, sem primeiro termos terminado a construção da placa de betão armado. Neste exemplo existe uma relação de dependência entre a atividade “Fazer a Placa de Betão Armado” e a atividade “Colocar as Placas de Cerâmica”. Enquanto a primeira não estiver concluída, a segunda atividade não pode ser iniciada.

Após dispormos de uma visão clara do produto ou serviço que vamos criar estamos em condições de começar a definir como vamos fazer, isto é quais as atividades necessárias. Definir as atividades é o processo de identificação das ações específicas a serem realizadas para produzir as entregas do projeto.

No processo 5.4 Criar a Estrutura Analítica (EAP / WBS), o nível inferior da EAP / WBS é designado como nível de pacotes de trabalho. Cada pacote de trabalho é constituído por várias atividades. Cada um desses pacotes de trabalho representa um ou vários entregáveis do projeto.

A utilização de protótipos para a coleta de requisitos (prototipagem) é uma técnica usada numa grande variedade de casos, nomeadamente quando necessitamos de obter rapidamente informações específicas sobre os requisitos de informação do utilizador. Nos últimos anos tem sido usado com êxito em projetos de desenvolvimento de produtos ou sistemas de software, quando se pretende manter o utilizador envolvido no projeto ou como forma de disponibilizar mais rapidamente algumas das funcionalidades do sistema.  Um protótipo é um modelo do produto final. Permite avaliar as reações do utilizador, ao produto que está a ser criado, facilitando a identificando dos requisitos do produto. Pode igualmente ser usado para a realização de testes de funcionalidades, segurança e qualidade.

Dependendo do tipo e da complexidade do projeto ele será mais ou menos extenso, com determinados capítulos mais ou menos desenvolvidos, sem no entanto se perder de vista que é: Um documento guia para o desenvolvimento futuro do projeto; Base para os processos de detalhe que se seguem no âmbito do processo de planeamento; Elaborado para explicar a todos os intervenientes a razão e os objetivos do projeto

De acordo com o PMBOK v5 a declaração do âmbito / Escopo do Projeto é um resultado do processo 5.2 Definir o Âmbito / Escopo e uma entrada do processo 5.3 Criar Estrutura Analítica Projeto (EAP / WBS).

A declaração do âmbito / escopo do projeto descreve detalhadamente as entregas do projeto e o trabalho necessário para criar essas entregas, sendo um documento fundamental para criar, entre todos os envolvidos no projeto, um entendimento comum sobre os objetivos do projeto, o que vai ser feito e como vai ser feito.

No âmbito da gestão de projeto são habitualmente referidas a criação de três tipos de diagramas de estrutura hierárquica os quais são usados para identificar pessoas, produtos e atividades. Esses diagramas chamam-se, respetivamente, Estrutura Organizacional do Projeto / Organizational Breakdown Struture (EOP / OBS), Estrutura Funcional do Produto / Product Breakdown Struture (EFP / PBS) e Estrutura Analítica do Projeto / Work Breakdown Struture (EAP / WBS).

A maioria dos projetos necessita de recursos que pertencem a mais do que uma organização ou departamento. A utilização de um diagrama que descreva de forma hierárquica a estrutura funcional das pessoas que têm de trabalhar no projeto ajuda a identificar as responsabilidades, as respetivas hierarquias, e clarifica os relacionamentos e as conexões que existem entre os diversos departamentos e organizações intervenientes.

A EOP / OBS define a equipa do projeto na medida em que é construída tendo como quadro de referência as atividades que têm de ser realizadas, e com o intuito de conhecer e validar os responsáveis para cada uma dessas atividades.

O que é a EFP / PBS?

A EFP / PBS consiste na representação gráfica da estrutura hierárquica dos produtos e subprodutos do projeto. Para criar a EFP / PBS é em primeiro lugar necessário identificar os requisitos que o cliente do projeto tem para o produto que irá ser criado no âmbito do projeto. Uma vez identificado o produto que o cliente deseja, é necessário identificar os produtos necessários para construir e suportar o produto do cliente. Nestes últimos incluem-se os produtos decorrentes das atividades de gestão do projeto (por exemplo planos e relatórios).

Um Gestor de Projeto é essencialmente uma pessoa organizada e com um leque de competências abrangente que abarcam, desde as competências de negócio, até às competências na gestão de pessoas, passando pelas competências técnicas e de gestão de projeto.

Um bom Gestor de Projeto tem de possuir uma vasta variedade de habilitações (skills), devendo obrigatoriamente deter capacidades aprofundadas nas áreas da Liderança, Comunicação, Gestão de Pessoas, Negociação e Resolução de Problemas.

O processo de controlo do âmbito tem por objetivo influenciar os fatores que criam alterações ao âmbito do projeto, controlando o impacto dessas alterações. O controlo de âmbito assegura que todas as alterações solicitadas e propostas de correção recomendadas são feitas e processadas no âmbito do processo integrado de controlo de alterações.

As alterações são inevitáveis, logo tem que existir um processo que permita o seu controlo. Alterações não controladas são referidas na terminologia de gestão de projetos como “Scope Creep / Descontrolo de Âmbito ou Escopo”.

A capacidade de tomar notas de forma eficiente é um fator determinante para a correta identificação das necessidades e expetativas das partes interessadas, as quais se irão posteriormente transformar nos requisitos do produto e do projeto.

Existem muitas maneiras de tirar anotações, e cada pessoa usará a que mais se adapta às suas necessidades e ao contexto do trabalho que está a realizar. Com ligeiras alterações para o adaptar melhor ao contexto da gestão de projeto, o que a seguir se apresenta é, um método bastante eficaz e muito divulgado, conhecido por Sistema Cornell e que foi desenvolvido por Walter Pauk, da Universidade de Cornell.

As técnicas de decisão em grupo têm por objetivo conseguir que grupos de peritos discutam um determinado assunto e avaliem múltiplas alternativas de forma a chegar à melhor solução de conjunto.

A Técnica Delphi é uma técnica não interativa (em que o grupo não se reúne) mas que funciona por ciclos. Vários especialistas, individualmente e geralmente de forma anónima, apresentam ideias e justificações sobre determinado assunto. Até que se chegue à solução final a Técnica Delphi funciona por ciclos. Em cada ciclo um facilitador recolhe as opiniões e fornece a todos um sumário das ideias e razões apresentadas; Com base nessa informação os especialistas reveem a sua posição, alteram-na ou apresentam novos argumentos. Ao fim de um determinado número de ciclos dever-se-á ter chegado a uma solução ou conjunto de soluções que é reconhecido pela generalidade dos participantes como a melhor solução.

A Matriz de Rastreabilidade de Requisitos – MRR / (Requirements Traceability Matrix – RTM) é uma tabela que relaciona as funcionalidades e funções do produto com as suas origens (os requisitos) do produto ou do projeto.

A utilidade da Matriz de Rastreabilidade de Requisitos – MRR / RTM é a de permitir:
Compreender a razão de ser das funções ou funcionalidades do produto ligando-a a um ou vários requisitos do cliente Gerir o âmbito / escopo do produto e do projeto Gerir as alterações aos requisitos Avaliar o impacto no projeto relativo à mudança de um requisito Avaliar o impacto da falha de um teste nos requisitos (isto é se o teste falha talvez o requisito não seja atingido) Verificar se todos os requisitos do sistema estão implementados Verificar se o produto ou serviço criado pelo projeto tem as funcionalidades esperadas (faz aquilo que era suposto fazer)

Verificar o âmbito / escopo é o processo de obtenção da aceitação formal dos entregáveis do projeto. Inclui a revisão das entregas feitas de forma a garantir que cada uma delas foi concluída de forma satisfatória para o cliente ou para o promotor do projeto. Se o projeto for finalizado antes da conclusão (cancelado), o processo de verificação do âmbito / escopo deve determinar e documentar o grau de conclusão que o projeto atingiu (quais os entregáveis que foram completados e entregues e quais os que não foram).

As técnicas de decisão em grupo têm por objetivo conseguir que grupos de peritos discutam um determinado assunto e avaliem múltiplas alternativas de forma a chegar à melhor solução de conjunto.

Essencialmente existem dois tipos de técnicas de decisão em grupo, a Técnica Nominal de Grupo e a Técnica Delphi. A Técnica Nominal de Grupo (TNG) é uma técnica de tomada de decisão em grupo cuja caraterística fundamental é o facto dos elementos do grupo, apesar de frente a frente em reunião, apresentarem as suas ideias de forma sistemática e totalmente independente.