PM2ALL - Gestão de Projetos | Agile Management | Outsourcing | Procurement | Contracting

Para que o método da Corrente Crítica possa ser usado com sucesso é necessária uma profunda mudança de cultura na organização, desde logo porque o método assenta num novo paradigma em relação à estimação da duração das atividades (ver artigos anteriores sobre o Método da Corrente Crítica, Parte 1 e Parte 2 ). Os autores do Método da Corrente Crítica, como alternativa ao Método do Caminho Crítico , defendem que este último é o responsável por muitos dos problemas de incumprimento dos prazos com que a generalidade dos projetos se debate.

O processo de controlo de cronograma centra-se em: Determinar o estado atual da execução do cronograma do projeto; Influenciar os fatores que criam alterações ao cronograma; Determinar se o cronograma do projeto mudou; Gerir as mudanças quando elas ocorrem.  Para calcular a variância do cronograma usa-se os pacotes de trabalho ou os pontos de controlo contabilístico, contidos na WBS .

O livro A Guide to the Project Management Body of Knowledge ou Guia para o Conjunto de Conhecimentos de Gestão de Projetos, mais conhecido como “ PMBOK Guide ”, é da autoria do Standards Committee (Comité de Padronização) do Project Management Institute – PMI . O PMBOK tem como objetivo identificar o conjunto de conhecimentos de gestão de projetos que são amplamente reconhecidos como boa prática. Ser amplamente reconhecido significa que é aplicável na maior parte do tempo e que existe um consenso em relação à sua utilidade.

Como vimos no artigo sobre como Gerir o Valor Agregado do Projeto (GVA / EVM) , é através desta ferramenta que se consegue medir com precisão o estado atual do projeto e determinar tendências que nos permitam efetuar previsões em relação à conclusão . No seu significado mais corrente, o Valor Agregado consiste em conhecer a quantidade de trabalho executado, para um determinado montante de dinheiro despendido, durante um período específico de tempo . Segundo esta definição o Valor Agregado permite saber se obtivemos aquilo pelo que pagámos.  

O método de gestão de projetos  usado pela maioria das empresas considera que, após a definição do âmbito / escopo do projeto, e da sua decomposição em pacotes de trabalho, identificam-se as atividades que deverão ser executadas para gerar os produtos ou serviços que são o objetivo final do projeto. Neste modelo, após as estimativas de duração das atividades, deve elaborar-se o diagrama de rede, calcular as datas cedo e tarde, de início e término e identificar o caminho crítico, que é definido como sendo o caminho que determina a duração do projeto.  

Uma caraterística comum à generalidade dos projetos é a sua elevada taxa de insucesso. A experiência demonstra-nos que todos os projetos têm uma elevada probabilidade de desvios no orçamento, atrasos nas datas planeadas e comprometimento do âmbito / escopo do projeto. A tendência é para colocar a culpa na incerteza que é caraterística de qualquer projeto, o que leva os gestores de projeto e as suas equipas a colocar uma grande margem de segurança no planeamento, considerando realistas estimativas que, de facto, se baseiam na pior experiência anterior, frequentemente acrescida de uma margem para o caso de as coisas ainda correrem pior, e não informando quanto de proteção colocam em cada uma das atividades do projeto.  

A utilização do método do caminho crítico produz um calendário que pode exigir, durante um determinado tempo, mais recursos que os disponíveis , ou obrigar a alterações nos níveis de recursos que não possam ser geríveis ou que não sejam compatíveis com os requisitos do projeto.   É muito frequente, quase inevitável, que na primeira versão do cronograma do projeto, existam recursos que têm um nível de utilização no projeto que é superior à sua disponibilidade.  

O diagrama de Gantt é uma forma gráfica de representar graficamente o calendário das atividades do projeto e respetivas dependências. O diagrama Gantt representa as atividades do projeto num espaço bidimensional em que, na horizontal está marcado o tempo de duração do projeto, numa escala que pode ser de dias, semanas, meses, ou outra), e na horizontal se encontram as diversas atividades do projeto.

Quando falamos do Método PERT , devemos distinguir duas ferramentas: o Diagrama PERT , que é uma das formas de representar uma rede de atividades e a Estimativa PERT , ou método de estimação por três pontos, que é o método de estimação baseado na média ponderada de três estimativas (estimativa pessimista, estimativa mais provável, e estimativa otimista). Uma rede de atividades pode ser representada com o recurso a dois tipos de diagramas: Diagrama de Atividades no Nó , e Diagrama de Atividades na Seta . O Diagrama PERT (Programmed Evaluation and Review Technique) é outro nome que se pode usar para designar o Diagrama de Atividades na Seta .  

Após a elaboração do primeiro cronograma do projeto podemos chegar à conclusão que o tempo necessário para a conclusão é impraticável porque: Não cumpre com os requisitos do cliente; Não respeita os compromissos contratuais; Não permite disponibilizar o produto ou serviço no momento exigido pelo mercado (Time-to-market); Não permite receber o bónus ou a compensação definida no contrato; Não está de acordo com as datas em que necessitamos de libertar os recursos do projeto (Por exemplo, quando estes são necessários para outro projeto). Face a uma situação destas existem vários mecanismos e técnicas que podemos usar para acelerar o cronograma do projeto , e conseguir que o mesmo termine na data desejada. No entanto, temos de ter presente que, qualquer que seja o mecanismo ou técnica usada, isso terá quase sempre como consequência um aumento do custo do projeto .  

Ao recorrer à contratação externa, a organização delega a responsabilidade de executar determinadas funções de negócio. No entanto, deve ter-se presente que, se bem que o produto ou serviço possa ser externalizado, o risco não é externalizável e que por isso, ao contrário do frequentemente referido e percecionado por alguns decisores, o outsourcing representa sempre um aumento do risco para o cliente . Ao avançar para uma relação de outsourcing e, em particular, num relacionamento de longo prazo, muito por via dos elevados custos de reversibilidade da operação, o cliente assume uma importante fatia dos riscos do fornecedor .

O termo outsourcing designa o recurso a fontes externas para a execução de atividades que, tradicionalmente, são efetuadas por recursos internos á organização . Nos sistemas e tecnologias de informação (SI/TI), este tipo de recurso é, desde há muito, usado por organizações que se aperceberam da sua potencialidade para lidar de forma eficaz, com um conjunto de problemas com que os departamentos internos de tecnologias e sistemas de informação habitualmente se debatem.

O resultado final do diagrama de rede é identificar o caminho crítico, ou os caminhos críticos, para o projeto.    Como se disse em artigo anterior, o processo de criação do cronograma do projeto passa por duas fases: 1) Criação do calendário ideal; 2) Inclusão das disponibilidades de recursos e das várias restrições e dependências com impacto no calendário. Essas dependências devem ser agrupadas em 3 categorias , relacionadas com as respetivas origens (ver o artigo sobre o Diagrama de Precedências – MDP ): Obrigatórias - Exigidas contratualmente ou inerente à natureza do trabalho. Arbitradas - Sequência preferencial/desejável com base nas melhores práticas. Externas - Relacionamento com atividades que não dependem do projeto.   O caminho crítico de um projeto é definido como sendo “ A cadeia / sequência de atividades do projeto que tem a menor folga (habitualmente folga zero) em relação às datas de início e de fim ”.  

Desenvolver o cronograma do projeto consiste no processo de análise das sequências de atividades, suas durações, recursos necessários e restrições do cronograma com o objetivo de criar um calendário realista para as atividades do projeto e que possa ser usado como a linha base de calendário . Criar o cronograma do projeto consiste em determinar as datas de início e de fim para cada uma das atividades do projeto. Se essas datas não forem realísticas é improvável que o projeto cumpra o calendário e termine na data planeada.

Estimar as durações das atividades do projeto consiste em p rever 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.

Os projetos são terrenos férteis para reuniões. Uma das tarefas importantes do gestor de projeto consiste em gerir corretamente o tempo ocupado em reuniões, garantindo a sua eficiência. A maioria dos projetos sofre de uma doença grave que dá pelo nome de Reunite .   As causas são múltiplas, desde logo porque essa doença está mais ou menos generalizada, fazendo parte da nossa tradição cultural. Esta Reunite tem como sintomas mais visíveis aquilo que, na gíria, chamamos de REPONE (Reunião de Porra Nenhuma) . 

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 r elaçõ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.

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  

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 produção de um produto ou serviço requer a coordenação do esforço individual de numerosos especialistas, com múltiplos e diferentes tipos de conhecimento. As organizações são entidades integradoras de conhecimento, na medida em que, existindo como instituições para a produção de bens e serviços, conseguem criar as condições mediante as quais um conjunto alargado de indivíduos integra, nesses produtos e serviços, conhecimento individual e especializado.

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.

As técnicas de criatividade em grupo são usadas com o objetivo de potenciar a discussão e a troca de ideias. O objetivo é que dessa troca e partilha livre de opiniões possam surgir soluções criativas, mais inovadoras e, sobretudo, partilhadas e aceites por todos.   A técnica de criatividade em grupo mais conhecida é o Brainstorming “Tempestade de Ideias” , que pode ser definida como “uma técnica de conferência através da qual um grupo de pessoas procura, através da discussão crítica de ideias espontâneas, encontrar uma solução para um problema específico”. No âmbito das sessões de Brainstorming é por vezes utilizada uma técnica de ajuda à exposição de ideias conhecida pelo nome de Mind Mapping (Mapas Mentais) , à qual nos referiremos em próximo artigo.

A observação, também conhecida por “ Job Shadowing ” é uma técnica do processo 5.1 Coletar os Requisitos que fornece uma maneira direta de examinar o dia-a-dia de uma empresa ou indivíduo no seu ambiente próprio, desempenhando o seu trabalho e executando processos. Quando aplicada no âmbito do processo de coleta de requisitos, é uma técnica particularmente útil para descrever detalhes de processos que as pessoas que usam o produto ou serviço têm dificuldade em expressar, tornando possível encontrar requisitos do projeto, produto ou serviço que de outra forma poderiam passar despercebidos quer devido á relutância dos interessados em expressar esse requisito, quer porque o mesmo está tão presente no seu dia-a-dia que passou a ser entendido como algo natural e portanto difícil de ser identificado de forma clara.

Uma entrevista é um meio formal ou informal de, através de conversas diretas, recolher informações das partes interessadas. As entrevistas, que podem decorrer individualmente ou em grupo, baseiam-se no registo das respostas a um determinado conjunto de perguntas. Estas podem ter sido previamente preparadas – a entrevista obedece a um guião predefinido - ou ser realizadas de forma espontânea à medida que a conversa decorre.

Conjunto de questões escritas apresentadas ao cliente ou a outras partes interessados do projeto com o intuito de recolher informação objetiva (fatos) ou de caráter mais subjetivo (opiniões) sobre o projeto ou sobre o produto ou serviço que se pretende criar. Após a coleta das respostas, os dados obtidos devem ser tratados de forma a extrair informação quantitativa e/ou qualitativa que permita definir requisitos a incluir no projeto, produto ou serviço.

As equipas de projeto utilizam frequentemente as entrevistas como ferramenta para a recolha de informação qualitativa. Um Focus-Group, em português "Discussão em Grupo", é uma variação da técnica de entrevistas em grupo, usada frequentemente para capturar as perceções e os sentimentos dos participantes inquiridos sobre um determinado assunto. O Focus-Group pode ser usado como o primeiro passo na coleta dos requisitos do projeto, ou como forma de aprofundar o conhecimento. Tipicamente, aos participantes começam por ser colocadas questões genéricas, as quais se vão tornando cada vez mais especificas à medida que determinado requisito ou conjunto de requisitos vai sendo delineado.

O processo de recolha de requisitos é interativo sendo aprofundado à medida que as diversas partes interessadas vão transmitindo as suas necessidades. Uma ferramenta útil, e que nos permite avaliar se o processo de recolha de requisitos está mais ou menos completa, consiste na catalogação dos requisitos por tipo de acordo com aquilo que podemos chamar a roda de requisitos. Esta classificação não garante que, a um dado momento do projeto, os requisitos estejam completos, isso depende de muitos outros fatores, nomeadamente de uma correta identificação das partes interessadas no projeto e da utilização correta das diversas ferramentas que estão ao dispor do gestor de projeto e da sua equipa para a coleta dos requisitos do projeto e do produto ou serviço que se pretende criar.

O Plano de Gestão do Projeto é usado para guiar a execução do projeto e servir como base para o controle de todo o projeto, por isso ele é composto por todos os outros documentos de planeamento sendo igualmente utilizado como uma importante ferramenta de comunicação com todos os envolvidos no projeto. O plano deverá reunir todos os outros planos setoriais. O resultado será um documento elaborado progressivamente ao longo do projeto sendo que, no primeiro ciclo, os documentos auxiliares de planeamento poderão ainda não existir ou existir de forma muito incipiente. Devido à sua importância para o sucesso do projeto ele deve ser formalmente apresentado e aprovado pelo promotor do projeto e pelas restantes partes interessadas relevantes.

Apesar da sua importância para o sucesso do projeto, o encerramento formal do projeto é um dos processos mais descorados pelos gestores e pelas equipas de projeto. O processo 4.6 Encerrar o Projeto ou Fase permite assegurar que todas as atividades e processos de gestão do projeto foram adequadamente terminados e que as entregáveis programados foram entregues ao cliente e por ele aceites.

Nos últimos anos têm sido efetuados vários estudos sobre o efeito das tecnologias Web 2.0 nas organizações. Um inquérito efetuado pela McKinsey a 2847 executivos em todo o mundo revelou que mais de 75% dos respondentes pretendem aumentar os seus investimentos em tecnologias que encorajam a colaboração entre utilizadores e mais de 50% referiram estar satisfeitos com os investimentos feitos até ao momento mesmo que 42% considerem que deveriam ter investido mais na criação de capacidades internas da organização para aproveitar as ferramentas colaborativas.

A utilização de Opinião Especializada, também conhecida por Avaliação por Peritos, é uma ferramenta / técnica usada em múltiplos processos do PMBOK v5. Consiste na recolha e avaliação com base nas opiniões fornecidas por especialistas em uma determinada área de aplicação, área de conhecimento, disciplina ou setor que seja relevante para a atividade que está a ser realizada. Essa especialização pode ser oferecida por qualquer grupo ou pessoa com formação, habilidade, experiência ou conhecimento especializado e está disponível a partir de diversas fontes:

Desde o seu nascimento muitos autores entenderam que o conceito de Web 2.0 ia muito para além do plano tecnológico representando uma alteração do paradigma em termos da criação coletiva do conhecimento. O termo Web 2.0 foi criado em 2004 por Tim O’Reilly e, nos últimos anos, tem sido crescentemente usado no contexto da gestão (Conhecimento 2.0, Processo de Decisão 2.0, Organização 2.0, Gestão do Conhecimento 2.0) refletindo o impacto cada vez maior do conceito nas organizações.  

Não sendo frequente, exceto em casos muito específicos, nem em certa medida desejável que a fase de execução do projeto decorra exatamente conforme o planeado (isso impediria o projeto de incluir na sua execução do conhecimento adquirido ao longo da execução e impediria qualquer ação de correção de potenciais desvios), é necessário que exista um processo que, de forma integrada, tenha como objetivo avaliar, aprovar e controlar as alterações propostas independentemente do seu tipo (âmbito, custo, duração).

Monitorar e controlar o trabalho do projeto é o processo de acompanhamento, revisão e ajuste da evolução do projeto de forma a cumprir com os objetivos de desempenho definidos no plano de gestão do projeto. Deste processo constam as atividades de recolha, medição e disseminação das informações sobre o desempenho do projeto, nas quais se inclui a avaliação da tendência de evolução futura de forma a implementar melhorias e correções no processo.

Este é basicamente o processo em que se coloca em prática o plano de gestão do projeto. Sendo uma metodologia genérica não existem no PMBOK indicações sobre como gerir projetos específicos (Por exemplo projetos de construção civil ou desenvolvimento de software). Para gerir projetos em áreas muito especificas o gestor de projeto deve conhecer e seguir as boas-práticas das indústrias em causa.

As organizações funcionam baseadas em processos. Esses processos visam a obtenção de determinados resultados. Os Ativos e Processos da Organização são os resultados dos processos implementados na organização em que o projeto decorre. À semelhança do que acontece com os Fatores Ambientais da Organização também os Ativos de Processos Organizacionais servem de entrada à maioria dos processos de planeamento do PMBOK v5. No entanto, enquanto os primeiros são vistos como fatores que condicionam as opções de gestão do projeto e influenciam, positiva ou negativamente, os Ativos de Processos Organizacionais são sobretudo entendidos como fatores que ajudam à gestão e ao sucesso do projeto na medida em que representam o conhecimento que a organização obteve em projetos anteriores.

Os Fatores Ambientais da Empresa referem-se a fatores internos e externos relacionados com o ambiente da organização onde o projeto decorre. Sendo entradas frequentes nos processos de planeamento do PMBOK, condicionam as opções de gestão do projeto e influenciam, positiva ou negativamente o resultado do projeto. O conjunto de Fatores Ambientais da Organização é muito diverso. O PMBOK descreve o subconjunto dos fatores mais relevantes para cada um dos processos considerados, devendo o gestor de projeto ter em atenção que, dependendo da especificidade do projeto e da organização, outros podem existir.

O Plano de Gestão do Projeto é documento que explica a forma como o projeto irá ser gerido, incluindo as ações necessárias para definir, coordenar e integrar todos os planos setoriais (Âmbito, Calendário, Custo, Qualidade, Risco, Comunicação, Recursos Humanos, Aquisições e Expectativas dos Interessados) num documento único que permita a gestão eficaz do projeto.  

A maioria das tecnologias de informação e comunicação atualmente usadas nas organizações podem ser agrupadas em duas categorias: Canais – Tecnologia de e-mail e mensagens instantâneas a qual permite que a informação seja criada e distribuída por todos A produção é descentralizada e existe um baixo grau de significado comum. Plataformas – Por exemplo a intranet, web corporativa e portais informativos, que em certa medida são tecnologias opostas às de canal, na medida em que o conteúdo é gerado ou, pelo menos, aprovado por um pequeno grupo de pessoas podendo depois ser visualizado por todos sendo a produção centralizada e o significado comum é elevado. Estas tecnologias apresentam dois tipos de problemas.