Gerenciamento de Projetos

Da Wikipédia, a enciclopédia livre
Ir para navegação Pular para pesquisar

O gerenciamento de projetos é o processo de liderar o trabalho de uma equipe para atingir todas as metas do projeto dentro das restrições fornecidas. [1] Essas informações geralmente são descritas na documentação do projeto, criada no início do processo de desenvolvimento. As principais restrições são escopo , tempo, orçamento . [2] O desafio secundário é otimizar a alocação dos insumos necessários e aplicá-los para atender aos objetivos predefinidos.

O objetivo do gerenciamento de projetos é produzir um projeto completo que esteja de acordo com os objetivos do cliente. Em muitos casos, o objetivo do gerenciamento de projetos também é moldar ou reformar o briefing do cliente para abordar de forma viável os objetivos do cliente. Uma vez que os objetivos do cliente estejam claramente estabelecidos, eles devem influenciar todas as decisões tomadas por outras pessoas envolvidas no projeto - por exemplo, gerentes de projeto, designers, empreiteiros e sub-empreiteiros. Objetivos de gerenciamento de projetos mal definidos ou prescritos com muita rigidez são prejudiciais à tomada de decisões.

Um projeto é um esforço temporário projetado para produzir um produto, serviço ou resultado exclusivo com início e fim definidos (geralmente com restrição de tempo e, muitas vezes, restrito por financiamento ou pessoal) realizado para atender a metas e objetivos únicos, normalmente para trazer benefícios mudança ou valor agregado. [3] [4] A natureza temporária dos projetos contrasta com o business as usual (ou operações) , [5] que são atividades funcionais repetitivas, permanentes ou semipermanentes para produzir produtos ou serviços. Na prática, a gestão dessas abordagens de produção distintas requer o desenvolvimento de habilidades técnicas e estratégias de gestão distintas. [6]

História

Até 1900, os projetos de engenharia civil eram geralmente gerenciados por arquitetos criativos, engenheiros e mestres construtores , por exemplo, Vitruvius (primeiro século aC), Christopher Wren (1632-1723), Thomas Telford (1757-1834) e Isambard Kingdom Brunel ( 1806–1859). [7] Na década de 1950, as organizações começaram a aplicar sistematicamente ferramentas e técnicas de gerenciamento de projetos a projetos de engenharia complexos. [8]

Henry Gantt (1861-1919), o pai das técnicas de planejamento e controle

Como disciplina, a gestão de projetos desenvolveu-se a partir de vários campos de aplicação, incluindo construção civil, engenharia e atividade de defesa pesada . [9] Dois antepassados ​​do gerenciamento de projetos são Henry Gantt , chamado de pai das técnicas de planejamento e controle, [10] que é famoso por usar o gráfico de Gantt como uma ferramenta de gerenciamento de projetos (alternativamente, o Harmonograma proposto pela primeira vez por Karol Adamiecki [11] ); e Henri Fayol por sua criação das cinco funções de gerenciamento que formam a base do corpo de conhecimento associado ao gerenciamento de projetos e programas. [12]Tanto Gantt quanto Fayol foram estudantes das teorias de administração científica de Frederick Winslow Taylor . Seu trabalho é o precursor de ferramentas modernas de gerenciamento de projetos, incluindo estrutura analítica do trabalho (WBS) e alocação de recursos .

A década de 1950 marcou o início da era moderna de gerenciamento de projetos, onde os principais campos da engenharia se unem para trabalhar como um só. O gerenciamento de projetos passou a ser reconhecido como uma disciplina distinta decorrente da disciplina de gerenciamento com modelo de engenharia. [13] Nos Estados Unidos, antes da década de 1950, os projetos eram gerenciados em uma base ad-hoc, usando principalmente gráficos de Gantt e técnicas e ferramentas informais. Naquela época, dois modelos matemáticos de escalonamento de projetos foram desenvolvidos. O " método do caminho crítico " (CPM) foi desenvolvido como uma joint venture entre a DuPont Corporation e a Remington Rand Corporation para gerenciar projetos de manutenção de plantas. O "avaliação do programa e técnica de revisão "(PERT), foi desenvolvido pelo Escritório de Projetos Especiais da Marinha dos EUA em conjunto com a Lockheed Corporation e Booz Allen Hamilton como parte do programa de submarino de mísseis Polaris . [14]

PERT e CPM são muito semelhantes em sua abordagem, mas ainda apresentam algumas diferenças. CPM é usado para projetos que assumem tempos de atividade determinísticos; são conhecidos os horários em que cada atividade será realizada. O PERT, por outro lado, permite tempos de atividade estocástica; os horários em que cada atividade será realizada são incertos ou variados. Por causa dessa diferença central, CPM e PERT são usados ​​em contextos diferentes. Essas técnicas matemáticas rapidamente se espalharam por muitas empresas privadas.

Gráfico de rede PERT para um projeto de sete meses com cinco marcos

Ao mesmo tempo, conforme os modelos de agendamento de projetos estavam sendo desenvolvidos, a tecnologia para estimativa de custos de projetos , gerenciamento de custos e economia de engenharia estava evoluindo, com o trabalho pioneiro de Hans Lang e outros. Em 1956, a American Association of Cost Engineers (agora AACE International ; a Association for the Advancement of Cost Engineering ) foi formada pelos primeiros praticantes de gerenciamento de projetos e as especialidades associadas de planejamento e programação, estimativa de custos e controle de custo / cronograma (projeto ao controle). A AACE continuou seu trabalho pioneiro e em 2006 lançou o primeiro processo integrado para gerenciamento de portfólio, programa e projeto ( estrutura de gerenciamento de custo total ).

Em 1969, o Project Management Institute (PMI) foi formado nos EUA. [15] O PMI publica a versão original do Guia do Conhecimento em Gerenciamento de Projetos (Guia PMBOK) em 1996, com William Duncan como seu autor principal, que descreve as práticas de gerenciamento de projetos que são comuns à "maioria dos projetos, na maioria das vezes. " [16]

Tipos de gerenciamento de projetos

Os métodos de gerenciamento de projetos podem ser aplicados a qualquer projeto. Freqüentemente, é adaptado a um tipo específico de projeto com base no tamanho do projeto, natureza, indústria ou setor. Por exemplo, a indústria da construção, que se concentra na entrega de coisas como edifícios, estradas e pontes, desenvolveu sua própria forma especializada de gerenciamento de projeto, que se refere como gerenciamento de projeto de construção e na qual os gerentes de projeto podem ser treinados e certificados. [17] A indústria de tecnologia da informação também evoluiu para desenvolver sua própria forma de gerenciamento de projetos, que é conhecida como gerenciamento de projetos de TIe que é especializada na entrega de ativos técnicos e serviços que são necessários para passar por várias fases do ciclo de vida, como planejamento, design, desenvolvimento, teste e implantação. O gerenciamento de projetos de biotecnologia se concentra nos meandros da pesquisa e desenvolvimento em biotecnologia. [18] Gerenciamento de projetos de localizaçãoinclui a aplicação de muitas práticas padrão de gerenciamento de projetos para trabalhos de tradução, embora muitos considerem esse tipo de gerenciamento uma disciplina muito diferente. Existe uma gestão de projetos públicos que cobre todas as obras públicas do governo que podem ser realizadas por agências governamentais ou terceirizadas. Outra classificação de gerenciamento de projetos é baseada no tipo hard (físico) ou soft (não físico).

Comum entre todos os tipos de gerenciamento de projetos é que eles se concentram em três objetivos importantes: tempo, qualidade e orçamento. Projetos bem-sucedidos são concluídos no prazo, dentro do orçamento e de acordo com padrões de qualidade previamente acordados, ou seja, atendendo ao Triângulo de Ferro ou Restrição Tripla para que os projetos sejam considerados um sucesso ou fracasso. [19]

Para cada tipo de gerenciamento de projeto, os gerentes de projeto desenvolvem e utilizam modelos repetíveis que são específicos para o setor com o qual estão lidando. Isso permite que os planos do projeto se tornem muito completos e altamente repetíveis, com a intenção específica de aumentar a qualidade, reduzir os custos de entrega e diminuir o tempo para entregar os resultados do projeto.

Abordagens de gerenciamento de projetos

Um estudo de 2017 sugeriu que o sucesso de qualquer projeto depende de quão bem quatro aspectos principais estão alinhados com a dinâmica contextual que afeta o projeto, estes são referidos como os quatro P's : [20]

  • Plano : as atividades de planejamento e previsão.
  • Processo: A abordagem geral para todas as atividades e governança do projeto.
  • Pessoas: incluindo a dinâmica de como colaboram e se comunicam.
  • Poder: Linhas de autoridade, tomadores de decisão, organogramas, políticas de implementação e assim por diante.

Existem várias abordagens para organizar e concluir as atividades do projeto, incluindo: faseada, enxuta, iterativa e incremental. Existem também várias extensões para o planejamento do projeto, por exemplo, com base em resultados (com base no produto) ou atividades (com base no processo).

Independentemente da metodologia empregada, uma consideração cuidadosa deve ser dada aos objetivos gerais do projeto, cronograma e custo, bem como as funções e responsabilidades de todos os participantes e partes interessadas . [21]

Gestão de benefícios realização

O gerenciamento de realização de benefícios (BRM) aprimora as técnicas normais de gerenciamento de projetos por meio do foco nos resultados (benefícios) de um projeto, em vez de nos produtos ou saídas, e então medindo o grau em que isso está acontecendo para manter o projeto no caminho certo. Isso pode ajudar a reduzir o risco de um projeto concluído ser um fracasso, entregando os requisitos acordados (saídas), ou seja, o sucesso do projeto, mas falhando em entregar os benefícios (resultados) desses requisitos, ou seja, o sucesso do produto.

Além disso, as práticas de BRM visam garantir o alinhamento estratégico entre os resultados do projeto e as estratégias de negócios. A eficácia dessas práticas é apoiada por pesquisas recentes que evidenciam as práticas de BRM que influenciam o sucesso do projeto de uma perspectiva estratégica em diferentes países e setores. Esses efeitos mais amplos são chamados de impacto estratégico. [22]

Um exemplo de entrega de um projeto de acordo com os requisitos pode ser concordar em entregar um sistema de computador que processará os dados da equipe e gerenciará a folha de pagamento, feriados e registros de pessoal da equipe em tempos mais curtos, com redução de erros. De acordo com o BRM, o acordo pode ser para atingir uma redução especificada nas horas da equipe e nos erros necessários para processar e manter os dados da equipe após a instalação do sistema, em comparação com sem o sistema.

Critical gerenciamento de projetos cadeia

O gerenciamento de projetos de cadeia crítica (CCPM) é uma aplicação da teoria das restrições (TOC) ao planejamento e gerenciamento de projetos e é projetado para lidar com as incertezas inerentes ao gerenciamento de projetos, levando em consideração a disponibilidade limitada de recursos (habilidades físicas, humanas , bem como capacidade de gerenciamento e suporte) necessários para executar projetos.

O objetivo é aumentar o fluxo de projetos em uma organização ( throughput ). Aplicando as três primeiras das cinco etapas de foco da TOC, a restrição do sistema para todos os projetos, bem como os recursos, são identificados. Para explorar a restrição, as tarefas na cadeia crítica têm prioridade sobre todas as outras atividades. Finalmente, os projetos são planejados e gerenciados para garantir que os recursos estejam prontos quando as tarefas críticas da cadeia devem começar, subordinando todos os outros recursos à cadeia crítica.

Gerenciamento de valor agregado

O gerenciamento de valor agregado (EVM) estende o gerenciamento de projetos com técnicas para melhorar o monitoramento do projeto. Ele ilustra o progresso do projeto em direção à conclusão em termos de trabalho e valor (custo). A programação ganha é uma extensão da teoria e prática do EVM.

Gerenciamento iterativo e incremental projeto

Em estudos críticos de gerenciamento de projetos, observou-se que as abordagens em fases não são adequadas para projetos de grande escala e multi-empresa, [23] com requisitos indefinidos, ambíguos ou em rápida mudança, [24] ou aqueles com alto grau de risco, dependência e tecnologias em rápida mudança. [25] O cone de incerteza explica parte disso, pois o planejamento feito na fase inicial do projeto sofre de um alto grau de incerteza. Isso se torna especialmente verdadeiro porque o desenvolvimento de software geralmente é a realização de um produto novo ou inovador.

Essas complexidades são mais bem tratadas com uma abordagem mais exploratória ou iterativa e incremental. [26] Vários modelos de gerenciamento de projeto iterativo e incremental evoluíram, incluindo gerenciamento de projeto ágil , método de desenvolvimento de sistemas dinâmicos , gerenciamento de projeto extremo e Innovation Engineering®. [27]

Gestão lean projeto

O gerenciamento de projeto enxuto usa os princípios da manufatura enxuta para se concentrar na entrega de valor com menos desperdício e tempo reduzido.

Abordagem faseada

A abordagem em fases (ou em etapas) divide e gerencia o trabalho por meio de uma série de etapas distintas a serem concluídas, e é frequentemente referida como "tradicional" [28] ou " cascata ". [29] Embora possa variar, normalmente consiste em cinco áreas de processo, quatro fases mais o controle:

Fases típicas de desenvolvimento de um projeto de engenharia
  1. iniciação .
  2. planejamento e design .
  3. construção.
  4. monitoramento e controle.
  5. conclusão ou fechamento.

Muitos setores usam variações desses estágios do projeto e não é incomum que os estágios sejam renomeados para se adequar melhor à organização. Por exemplo, ao trabalhar em um projeto e construção de tijolo e argamassa , os projetos normalmente progridem por estágios como pré-planejamento, projeto conceitual, projeto esquemático, desenvolvimento de projeto, desenhos de construção (ou documentos de contrato) e administração de construção.

Embora a abordagem em fases funcione bem para projetos pequenos e bem definidos, geralmente resulta em desafio ou falha em projetos maiores, ou naqueles que são mais complexos ou têm mais ambiguidades, problemas e riscos. [30]

Gestão baseada em processo

A incorporação da gestão baseada em processos foi impulsionada pelo uso de modelos de maturidade, como o OPM3 e o CMMI (integração do modelo de maturidade de capacidade; veja este exemplo de um predecessor) e ISO / IEC 15504 (SPICE - melhoria de processo de software e estimativa de capacidade ) Ao contrário do CMM da SEI, o modelo de maturidade OPM3 descreve como tornar os processos de gerenciamento de projetos capazes de funcionar com sucesso, consistência e previsibilidade para implementar as estratégias de uma organização.

Projeto de gestão de produção

O gerenciamento de produção de projetos é a aplicação do gerenciamento de operações à entrega de projetos de capital. A estrutura de gerenciamento da produção do projeto é baseada em um projeto como uma visão do sistema de produção, em que um projeto transforma entradas (matérias-primas, informações, mão de obra, instalações e máquinas) em saídas (bens e serviços). [31]

Planejamento baseado em produto

O planejamento baseado em produtos é uma abordagem estruturada para gerenciamento de projetos, baseada na identificação de todos os produtos ( entregas do projeto ) que contribuem para atingir os objetivos do projeto. Como tal, define um projeto de sucesso como orientado para a produção, em vez de orientado para a atividade ou tarefa. [32] A implementação mais comum desta abordagem é PRINCE2 . [33]

Grupos de processos

As etapas de desenvolvimento do projeto [34]

Tradicionalmente (dependendo de qual metodologia de gerenciamento de projetos está sendo usada), o gerenciamento de projetos inclui vários elementos: quatro a cinco grupos de processos de gerenciamento de projetos e um sistema de controle. Independentemente da metodologia ou terminologia usada, os mesmos processos básicos de gerenciamento de projetos ou estágios de desenvolvimento serão usados. Os principais grupos de processos geralmente incluem: [35]

  • Iniciação
  • Planejamento
  • Produção ou execução
  • Monitoramento e controle
  • Fechando

Em ambientes de projeto com um elemento exploratório significativo (por exemplo, pesquisa e desenvolvimento ), essas etapas podem ser complementadas com pontos de decisão (decisões vai / não vai) em que a continuação do projeto é debatida e decidida. Um exemplo é o modelo Phase – gate .

Iniciando

Iniciando processos de grupo de processos [34]

Os processos de iniciação determinam a natureza e o escopo do projeto. [36] Se esta etapa não for bem executada, é improvável que o projeto seja bem-sucedido no atendimento às necessidades do negócio. Os principais controles de projeto necessários aqui são compreender o ambiente de negócios e garantir que todos os controles necessários sejam incorporados ao projeto. Quaisquer deficiências devem ser relatadas e uma recomendação deve ser feita para corrigi-las.

O estágio inicial deve incluir um plano que englobe as seguintes áreas. Essas áreas podem ser registradas em uma série de documentos chamados documentos de Iniciação do Projeto. Os documentos de iniciação do projeto são uma série de documentos planejados usados ​​para criar o pedido durante o projeto. Eles tendem a incluir:

Planejamento

Após o estágio de iniciação, o projeto é planejado com um nível de detalhe apropriado (veja o exemplo de um fluxograma ). [34] O objetivo principal é planejar tempo, custo e recursos de forma adequada para estimar o trabalho necessário e para gerenciar efetivamente os riscos durante a execução do projeto. Tal como acontece com o grupo de processos de Iniciação, uma falha em planejar adequadamente reduz muito as chances do projeto de atingir seus objetivos com sucesso.

O planejamento do projeto geralmente consiste em [37]

  • determinar a metodologia de gerenciamento de projetos a ser seguida (por exemplo, se o plano será definido totalmente no início , iterativamente ou em ondas sucessivas );
  • desenvolver a declaração de escopo ;
  • selecionar a equipe de planejamento;
  • identificar as entregas e criar as estruturas de divisão do produto e do trabalho;
  • identificar as atividades necessárias para concluir essas entregas e colocar em rede as atividades em sua sequência lógica;
  • estimar os requisitos de recursos para as atividades;
  • estimativa de tempo e custo para atividades;
  • desenvolver o cronograma;
  • desenvolver o orçamento;
  • planejamento de risco;
  • desenvolver medidas de garantia de qualidade;
  • obter aprovação formal para começar a trabalhar.

Processos adicionais, como planejamento para comunicações e gerenciamento de escopo, identificação de funções e responsabilidades, determinação do que comprar para o projeto e realização de uma reunião inicial também são geralmente aconselháveis.

Para projetos de desenvolvimento de novos produtos , o projeto conceitual da operação do produto final pode ser executado simultaneamente às atividades de planejamento do projeto e pode ajudar a informar a equipe de planejamento ao identificar as entregas e as atividades de planejamento.

Executando

Executando processos de grupo de processos [34]

Durante a execução, devemos saber quais são os termos planejados que precisam ser executados . A fase de execução / implementação garante que as entregas do plano de gerenciamento do projeto sejam executadas de acordo. Esta fase envolve a alocação, coordenação e gestão adequadas de recursos humanos e quaisquer outros recursos, como materiais e orçamentos. A saída desta fase são as entregas do projeto.

Projeto de Documentação

Documentar tudo dentro de um projeto é a chave para o sucesso. Para manter o orçamento, o escopo, a eficácia e o ritmo, um projeto deve ter documentos físicos relativos a cada tarefa específica. Com a documentação correta, é fácil ver se os requisitos de um projeto foram atendidos ou não. Para acompanhar isso, a documentação fornece informações sobre o que já foi concluído para aquele projeto. A documentação ao longo de um projeto fornece uma trilha de papel para quem precisa voltar e consultar o trabalho no passado. Na maioria dos casos, a documentação é a maneira mais bem-sucedida de monitorar e controlar as fases específicas de um projeto. Com a documentação correta, o sucesso de um projeto pode ser rastreado e observado à medida que o projeto avança. Se realizada corretamente, a documentação pode ser a espinha dorsal para o sucesso de um projeto

Monitoramento e controle

Monitorar e controlar os processos do grupo de processos [34]

Monitoramento e controle consistem nos processos executados para observar a execução do projeto, de forma que problemas potenciais possam ser identificados em tempo hábil e ações corretivas possam ser tomadas, quando necessário, para controlar a execução do projeto. O principal benefício é que o desempenho do projeto é observado e medido regularmente para identificar variações do plano de gerenciamento do projeto.

O monitoramento e o controle incluem: [38]

  • Medir as atividades do projeto em andamento ('onde estamos');
  • Monitorar as variáveis ​​do projeto (custo, esforço, escopo, etc.) em relação ao plano de gerenciamento do projeto e a linha de base de desempenho do projeto ( onde devemos estar );
  • Identificar ações corretivas para abordar problemas e riscos de forma adequada ( como podemos voltar aos trilhos );
  • Influenciar os fatores que podem contornar o controle integrado de mudanças, de forma que apenas as mudanças aprovadas sejam implementadas.

Dois mecanismos principais apóiam o monitoramento e o controle dos projetos. Por um lado, os contratos oferecem um conjunto de regras e incentivos frequentemente apoiados por potenciais penalidades e sanções. [39] Por outro lado, os estudiosos em negócios e gestão pagaram atenção para o papel de integradores (também chamados barões do projeto) para atingir os objetivos do projeto. [40] [41] Por sua vez, pesquisas recentes em gerenciamento de projetos questionaram o tipo de interação entre contratos e integradores. Alguns argumentaram que esses dois mecanismos de monitoramento operam como substitutos [42], pois um tipo de organização diminuiria as vantagens de usar o outro, enquanto outros sugeriram que eles podem se complementar. [43]

Em projetos de várias fases, o processo de monitoramento e controle também fornece feedback entre as fases do projeto, para implementar ações corretivas ou preventivas para colocar o projeto em conformidade com o plano de gerenciamento do projeto.

A manutenção do projeto é um processo contínuo e inclui: [35]

  • Suporte contínuo aos usuários finais
  • Correção de erros
  • Atualizações do produto ao longo do tempo
Ciclo de monitoramento e controle

Nesse estágio, os auditores devem prestar atenção em como os problemas do usuário são resolvidos de forma eficaz e rápida.

Ao longo de qualquer projeto de construção, o escopo do trabalho pode mudar. A mudança é uma parte normal e esperada do processo de construção. As mudanças podem ser o resultado de modificações necessárias no projeto, diferentes condições do local, disponibilidade de material, mudanças solicitadas pelo empreiteiro, engenharia de valor e impactos de terceiros, para citar alguns. Além de executar a mudança no campo, a mudança normalmente precisa ser documentada para mostrar o que foi realmente construído. Isso é conhecido como gerenciamento de mudanças. Conseqüentemente, o proprietário geralmente requer um registro final para mostrar todas as alterações ou, mais especificamente, qualquer alteração que modifique as partes tangíveis da obra acabada. O registro é feito nos documentos do contrato - normalmente, mas não necessariamente limitado aos desenhos do projeto. O produto final desse esforço é o que a indústria chama de desenhos as-built,ou mais simplesmente, "conforme construído". A exigência de fornecê-los é norma nos contratos de construção. O gerenciamento de documentos de construção é uma tarefa muito importante realizada com o auxílio de um sistema de software online ou desktop, ou mantida por meio de documentação física. A crescente legalidade da manutenção de uma documentação correta pela indústria da construção tem acarretado o aumento da necessidade de sistemas de gestão documental.A manutenção da documentação correta tem causado o aumento da necessidade de sistemas de gerenciamento de documentos.A manutenção da documentação correta tem causado o aumento da necessidade de sistemas de gerenciamento de documentos.

Quando mudanças são introduzidas no projeto, a viabilidade do projeto deve ser reavaliada. É importante não perder de vista os objetivos e metas iniciais dos projetos. Quando as mudanças se acumulam, o resultado previsto pode não justificar o investimento original proposto no projeto. O gerenciamento bem-sucedido do projeto identifica esses componentes, rastreia e monitora o progresso, de modo a ficar dentro do prazo e do orçamento já traçados no início do projeto. Métodos exatos foram sugeridos para identificar os pontos de monitoramento mais informativos ao longo do ciclo de vida do projeto em relação ao seu progresso e duração esperada. [44]

Fechando

Fechamento de processos de grupo de processos. [34]

O encerramento inclui a aceitação formal do projeto e a sua finalização. As atividades administrativas incluem o arquivamento dos arquivos e a documentação das lições aprendidas.

Esta fase consiste em: [35]

  • Encerramento do contrato : Concluir e liquidar cada contrato (incluindo a resolução de quaisquer itens em aberto) e encerrar cada contrato aplicável ao projeto ou fase do projeto.
  • Encerramento do projeto : finalizar todas as atividades em todos os grupos de processos para encerrar formalmente o projeto ou uma fase do projeto

Também incluída nesta fase está a revisão pós-implementação. Esta é uma fase vital do projeto para a equipe do projeto aprender com as experiências e aplicar em projetos futuros. Normalmente, uma revisão pós-implementação consiste em observar as coisas que deram certo e analisar as que deram errado no projeto para descobrir as lições aprendidas.

Projeto controle e sistemas de controle de projeto

O controle de projetos (também conhecido como Engenharia de Custos ) deve ser estabelecido como uma função independente no gerenciamento de projetos. Ele implementa a função de verificação e controle durante o processamento de um projeto para reforçar o desempenho definido e os objetivos formais. [45] As tarefas de controle de projeto também são:

  • a criação de infraestrutura para o fornecimento da informação certa e sua atualização
  • o estabelecimento de uma forma de comunicar disparidades de parâmetros de projeto
  • o desenvolvimento da tecnologia da informação do projeto com base em uma intranet ou a determinação de um sistema de indicadores-chave de desempenho (KPI) do projeto
  • análises de divergência e geração de propostas para regulamentos de projetos potenciais [46]
  • o estabelecimento de métodos para realizar uma estrutura de projeto adequada, organização do fluxo de trabalho do projeto, controle e governança do projeto
  • criação de transparência entre os parâmetros do projeto [47]

O cumprimento e a implementação dessas tarefas podem ser alcançados pela aplicação de métodos e instrumentos específicos de controle de projeto. Os seguintes métodos de controle de projeto podem ser aplicados:

  • análise de investimento
  • análise de custo-benefício
  • análise de valor benefício
  • pesquisas de especialistas
  • cálculos de simulação
  • análise de perfil de risco
  • cálculos de sobretaxa
  • análise de tendência de marco
  • análise de tendência de custo
  • meta / comparação real [48]

O controle de projeto é o elemento de um projeto que o mantém sob controle, dentro do prazo e do orçamento. [38] O controle do projeto começa no início do projeto com o planejamento e termina no final do projeto com a revisão pós-implementação, com um envolvimento completo de cada etapa do processo. Os projetos podem ser auditados ou revisados ​​enquanto o projeto está em andamento. As auditorias formais são geralmente baseadas em risco ou conformidade e a administração irá direcionar os objetivos da auditoria. Um exame pode incluir uma comparação dos processos de gerenciamento de projetos aprovados com a forma como o projeto está realmente sendo gerenciado. [49]Cada projeto deve ser avaliado quanto ao nível apropriado de controle necessário: muito controle consome muito tempo, muito pouco controle é muito arriscado. Se o controle do projeto não for implementado corretamente, o custo para o negócio deve ser esclarecido em termos de erros e correções.

Os sistemas de controle são necessários para custo, risco , qualidade, comunicação, tempo, mudança, aquisição e recursos humanos. Além disso, os auditores devem considerar a importância dos projetos para as demonstrações financeiras , o quão dependentes as partes interessadas dependem dos controles e quantos controles existem. Os auditores devem revisar o processo de desenvolvimento e os procedimentos de como eles são implementados. O processo de desenvolvimento e a qualidade do produto final também podem ser avaliados se necessário ou solicitado. Uma empresa pode querer que a firma de auditoria esteja envolvida em todo o processo para detectar problemas mais cedo, para que possam ser corrigidos mais facilmente. Um auditor pode servir como consultor de controles como parte da equipe de desenvolvimento ou como auditor independente como parte de uma auditoria.

Às vezes, as empresas usam processos de desenvolvimento de sistemas formais. Isso ajuda a garantir que os sistemas sejam desenvolvidos com sucesso. Um processo formal é mais eficaz na criação de controles fortes, e os auditores devem revisar esse processo para confirmar se ele está bem projetado e é seguido na prática. Um bom plano de desenvolvimento de sistemas formais descreve:

  • Uma estratégia para alinhar o desenvolvimento com os objetivos mais amplos da organização
  • Padrões para novos sistemas
  • Políticas de gerenciamento de projetos para cronograma e orçamento
  • Procedimentos que descrevem o processo
  • Avaliação da qualidade da mudança

Características dos projectos

Existem cinco características importantes de um projeto. (i) Deve sempre ter datas de início e término específicas. (ii) Eles são executados e concluídos por um grupo de pessoas. (iii) A saída é a entrega em um produto ou serviço exclusivo. (iv) São de natureza temporária. (v) É elaborado progressivamente. exemplo: projetar um novo carro, escrever um livro.

Projeto Complexidade

A complexidade e sua natureza desempenham um papel importante na área de gerenciamento de projetos. Apesar de haver muitos debates sobre o assunto, os estudos sugerem indefinição e razoável compreensão da complexidade em relação à gestão de projetos complexos. [50] [51]

A complexidade do projeto é propriedade de um projeto que torna difícil entender, prever e manter sob controle seu comportamento geral, mesmo quando recebe informações razoavelmente completas sobre o sistema do projeto. [52] A identificação de projetos complexos é especificamente importante para ambientes de engenharia de multiprojetos. [53]

Como se considera que a complexidade e o desempenho do projeto estão intimamente relacionados, é importante definir e medir a complexidade do projeto para que o gerenciamento do projeto seja eficaz. [54]

A complexidade pode ser:

  • Complexidade estrutural (também conhecida como complexidade de detalhes ou complicação), ou seja, consistindo de muitas partes inter-relacionadas variadas. [55] É tipicamente expresso em termos de tamanho, variedade e interdependência dos componentes do projeto, e descrito por fatores tecnológicos e organizacionais.
  • Complexidade dinâmica, que se refere a fenômenos, características e manifestações como ambigüidade, incerteza, propagação, emergência e caos. [52]

Com base na estrutura Cynefin , [56] projetos complexos podem ser classificados como:

  • Projetos, sistemas ou contextos simples (ou claros, óbvios, conhecidos). Estes são caracterizados por conhecidos conhecidos, estabilidade, relações claras de causa e efeito. Eles podem ser resolvidos com procedimentos operacionais padrão e melhores práticas.
  • Complicado : caracterizado por desconhecidos conhecidos. Um sistema complicado é a soma de suas partes. Em princípio, ele pode ser desconstruído em componentes menores e mais simples. Embora difíceis, problemas complicados são teoricamente solucionáveis ​​com recursos adicionais, com conhecimentos especializados, com técnicas analíticas, reducionistas, de simplificação, de decomposição, com planejamento de cenários e seguindo boas práticas. [57] [58]
  • Complexo : caracterizado por desconhecidos desconhecidos e emergência. Padrões podem ser descobertos, mas não são óbvios. Um sistema complexo pode ser descrito pela declaração de Aristóteles de que o todo é mais do que a soma de suas partes.
  • Projetos realmente complexos , também conhecidos como muito complexos ou caóticos: caracterizados por incognoscíveis. Nenhum padrão é discernível em projetos realmente complexos. As causas e efeitos não são claros, mesmo em retrospecto. Parafraseando Aristóteles , um sistema realmente complexo é diferente da soma de suas partes.

Ao aplicar a descoberta na medição da complexidade do trabalho descrita em Organização de Requisitos e Teoria de Sistemas Estratificados, o Dr. Elliott Jaques classifica os projetos e o trabalho do projeto (estágios, tarefas) em 7 níveis básicos de complexidade do projeto com base em critérios como intervalo de tempo de discrição e complexidade de saída de um projeto: [59] [60]

  • Projeto de nível 1 - melhora a produção direta de uma atividade (quantidade, qualidade, tempo) dentro de um processo de negócios com tempo de conclusão planejado de até 3 meses.
  • Projeto de nível 2 - desenvolver e melhorar a conformidade com um processo de negócios com tempo de conclusão planejado de 3 meses a 1 ano.
  • Projeto de nível 3 - desenvolver, alterar e melhorar um processo de negócios com tempo de conclusão planejado de 1 a 2 anos.
  • Projeto de nível 4 - desenvolver, alterar e melhorar um sistema funcional com tempo de conclusão planejado de 2 a 5 anos.
  • Projeto de nível 5 - desenvolver, alterar e melhorar um grupo de sistemas funcionais / função de negócios com tempo de conclusão planejado de 5 a 10 anos.
  • Projeto de nível 6 - desenvolver, mudar e melhorar toda uma única cadeia de valor de uma empresa com tempo de conclusão planejado de 10 a 20 anos.
  • Projeto Nível 7 - desenvolver, alterar e melhorar as múltiplas cadeias de valor de uma empresa com prazo de conclusão previsto de 20 a 50 anos. [61]

Os benefícios de medir a complexidade do projeto é melhorar a viabilidade do pessoal do projeto: [62]

  • Combine o nível de complexidade de um projeto com o tempo de conclusão efetivo almejado de um projeto
  • Combine o nível de complexidade de um projeto com o respectivo nível de capacidade do gerente de projeto
  • Combine o nível de complexidade de uma tarefa do projeto com a capacidade respectiva dos membros do projeto

Positivo, Apropriada (Requisite), e negativa Complexidade

Da mesma forma com a lei da variedade de requisitos e a lei da complexidade de requisitos , a complexidade do projeto às vezes é necessária para que o projeto alcance seus objetivos, e às vezes tem resultados benéficos. Com base nos efeitos, a complexidade do projeto pode, portanto, ser classificada como Positiva, Apropriada ou Negativa. [63]

  • A complexidade positiva é a complexidade que agrega valor ao projeto e cuja contribuição para o sucesso do projeto supera as consequências negativas associadas.
  • Complexidade apropriada (ou necessária) é a complexidade necessária para que o projeto alcance seus objetivos, ou cuja contribuição para o sucesso do projeto equilibre os efeitos negativos, ou o custo da mitigação supere as manifestações negativas.
  • A complexidade negativa é a complexidade que impede o sucesso do projeto.

Os gerentes de projeto

Um gerente de projeto é um profissional da área de gerenciamento de projetos. Os gerentes de projeto são responsáveis ​​pelas pessoas em um projeto. As pessoas são a chave para qualquer projeto de sucesso. Sem as pessoas certas no lugar certo e na hora certa, um projeto não pode ser bem-sucedido. Os gerentes de projeto podem ser responsáveis ​​pelo planejamento, execução, controle e fechamento de qualquer projeto normalmente relacionado à indústria de construção , engenharia, arquitetura, computação e telecomunicações. Muitos outros campos da engenharia de produção, engenharia de design e indústria pesada têm gerentes de projeto.

Um gerente de projeto precisa entender a ordem de execução de um projeto para agendá-lo corretamente, bem como o tempo necessário para realizar cada tarefa individual dentro do projeto. Um gerente de projeto é a pessoa responsável por cumprir os objetivos do projeto declarados em nome do cliente. Os gerentes de projeto tendem a ter vários anos de experiência em seu campo. Um gerente de projeto deve conhecer o projeto dentro e fora enquanto supervisiona os trabalhadores junto com o projeto. Normalmente, na maioria dos projetos de construção, engenharia, arquitetura e industriais, um gerente de projeto tem outro gerente trabalhando ao lado dele, que normalmente é responsável pela execução da tarefa em uma base diária. Esta posição em alguns casos é conhecida como superintendente.Um superintendente e um gerente de projeto trabalham lado a lado na conclusão das tarefas diárias do projeto. As principais responsabilidades de gerenciamento de projetos incluem a criação de objetivos de projeto claros e viáveis, construção dos requisitos do projeto e gerenciamento dorestrição tripla (agora incluindo mais restrições e chamando-a de restrições concorrentes) para projetos, que é custo, tempo, qualidade e escopo para os três primeiros, mas cerca de três adicionais no gerenciamento de projeto atual. Um projeto típico é composto por uma equipe de trabalhadores que trabalham sob o gerente de projeto para concluir a atribuição dentro das metas de tempo e orçamento. Um gerente de projeto normalmente se reporta diretamente a alguém de estatura superior na conclusão e no sucesso do projeto.

Um gerente de projeto geralmente é um representante do cliente e deve determinar e implementar as necessidades exatas do cliente, com base no conhecimento da empresa que está representando. A capacidade de se adaptar aos diversos procedimentos internos do contratante e de estabelecer laços estreitos com os representantes nomeados é essencial para garantir que as questões-chave de custo, prazo, qualidade e, acima de tudo, satisfação do cliente podem ser concretizadas.

Um gerente de projeto completo, um termo cunhado pela primeira vez pelo Dr. Robert J. Graham em sua simulação, foi expandido por Randall L. Englund e Alfonso Bucero. Eles descrevem um gerente de projeto completo como uma pessoa que adota várias disciplinas, como liderança, influência, negociações, política, gestão de mudanças e conflitos e humor. Todas essas são habilidades pessoais "suaves" que permitem que os líderes de projeto sejam mais eficazes e alcancem resultados otimizados e consistentes.

Framework multinível sucesso e critérios

Há uma tendência de confundir o sucesso do projeto com o sucesso do gerenciamento do projeto. São duas coisas diferentes. Os critérios de sucesso do gerenciamento de projetos são diferentes dos critérios de sucesso do projeto. O gerenciamento do projeto é considerado bem-sucedido se o projeto em questão for concluído dentro do prazo acordado, dentro do escopo acordado e dentro do orçamento acordado. Após as restrições triplas, várias restrições foram consideradas para garantir o sucesso do projeto. No entanto, as restrições triplas ou múltiplas indicam apenas as medidas de eficiência do projeto, que são de fato os critérios de sucesso do gerenciamento de projeto durante o ciclo de vida do projeto.

Os critérios a priori deixam de fora os resultados mais importantes após a conclusão do projeto, que compreendem quatro níveis, ou seja, o sucesso do produto (produto), o sucesso do resultado (benefícios) e o sucesso do impacto (estratégico) durante o ciclo de vida do produto. Esses critérios de sucesso posteriores indicam as medidas de eficácia do produto, serviço ou resultado do projeto, após a conclusão e transferência do projeto. Esta estrutura abrangente de sucesso de vários níveis de projetos, programas e portfólios foi desenvolvida por Paul Bannerman em 2008. [64]Em outras palavras, um projeto é considerado bem-sucedido quando consegue atingir o business case esperado, que precisa ser claramente identificado e definido durante o início e a seleção do projeto, antes de iniciar a fase de desenvolvimento. Essa estrutura de sucesso multinível está em conformidade com a teoria do projeto como uma transformação descrita como o impacto do processo de entrada / produção / resultado da atividade para gerar qualquer valor pretendido. Emanuel Camilleri em 2011 classifica todos os fatores críticos de sucesso e fracasso em grupos e combina cada um deles com os critérios de sucesso multinível para agregar valor ao negócio. [65]

Gestão de risco

Os estados do Departamento de Defesa dos Estados Unidos; "Custo, cronograma, desempenho e risco" são os quatro elementos por meio dos quais os profissionais de aquisição do Departamento de Defesa fazem compensações e rastreiam o status do programa. [66] Existem também padrões internacionais . O gerenciamento de riscos aplica a identificação proativa (consulte as ferramentas ) de problemas futuros e a compreensão de suas consequências, permitindo decisões preditivas sobre os projetos.

Estrutura analítica do projeto

A estrutura analítica do projeto (WBS) é uma estrutura em árvore que mostra uma subdivisão das atividades necessárias para atingir um objetivo - por exemplo, um portfólio, programa, projeto e contrato. A WBS pode ser orientada para hardware, produto, serviço ou processo (veja um exemplo em uma estrutura de relatório da NASA (2001) ). [67] Ao lado da WBS para gerenciamento do escopo do projeto, há estrutura analítica organizacional (gráfico) , estrutura analítica dos custos e estrutura analítica do risco .

Uma WBS pode ser desenvolvida começando com o objetivo final e sucessivamente subdividindo-o em componentes gerenciáveis ​​em termos de tamanho, duração e responsabilidade (por exemplo, sistemas, subsistemas, componentes, tarefas, subtarefas e pacotes de trabalho), que incluem todos passos necessários para atingir o objetivo. [30]

A estrutura analítica do trabalho fornece uma estrutura comum para o desenvolvimento natural do planejamento e controle geral de um contrato e é a base para dividir o trabalho em incrementos definíveis a partir dos quais a declaração de trabalho pode ser desenvolvida e técnica, cronograma, custo e hora de trabalho relatórios podem ser estabelecidos. [67] A estrutura analítica do projeto pode ser exibida em duas formas, como uma tabela com subdivisão de tarefas ou como um organograma cujos nós mais baixos são referidos como "pacotes de trabalho".

É um elemento essencial na avaliação da qualidade de um plano e um elemento inicial usado durante o planejamento do projeto. Por exemplo, uma WBS é usada quando o projeto é agendado, para que o uso de pacotes de trabalho possa ser registrado e rastreado.

Normas internacionais

Existem vários padrões de gerenciamento de projetos, incluindo:

  • As normas ISO ISO 9000 , uma família de normas para sistemas de gestão da qualidade, e a ISO 10006 : 2003, para sistemas de gestão da qualidade e diretrizes para a gestão da qualidade em projetos.
  • ISO 21500 : 2012 - Orientação sobre gerenciamento de projetos . Esta é a primeira Norma Internacional relacionada ao gerenciamento de projetos publicada pela ISO. Outros padrões na família 21500 incluem Orientação 21503: 2017 sobre gerenciamento de programas ; 21504: 2015 Orientação sobre gerenciamento de portfólio ; 21505: Orientações sobre governança de 2017 ; 21506: 2018 Vocabulário ; 21508: 2018 Gerenciamento de valor agregado em gerenciamento de projetos e programas ; e 21511: 2018 Estruturas analíticas do projeto para gerenciamento de projetos e programas.
  • ISO 31000 : 2009 - Gestão de riscos.
  • ISO / IEC / IEEE 16326: 2009 - Engenharia de Sistemas e Software - Processos de Ciclo de Vida - Gerenciamento de Projetos [68]
  • Linha de base de competência individual (ICB) da International Project Management Association (IPMA). [69]
  • Capability Maturity Model (CMM) do Software Engineering Institute .
  • GAPPS, Aliança Global para Padrões de Desempenho de Projetos - um padrão de código aberto que descreve COMPETÊNCIAS para gerentes de projetos e programas.
  • Método HERMES , método geral suíço de gestão de projetos, selecionado para uso em Luxemburgo e em organizações internacionais.
  • A abordagem de estrutura lógica (LFA), que é popular em organizações de desenvolvimento internacional.
  • Guia PMBOK do Project Management Institute (PMI).
  • PRINCE2 da AXELOS .
  • Team Software Process (TSP) do Software Engineering Institute .
  • Total Cost Management Framework, Metodologia da AACE International para Gestão Integrada de Portfólio, Programa e Projeto.
  • V-Model , um método original de desenvolvimento de sistemas.

Gestão do programa

Alguns projetos, idênticos ou diferentes, podem ser gerenciados como gerenciamento de programa, de forma que um gerente de programa seja responsável pelos gerentes de projeto. Portanto, um gerente de programa também é conhecido como diretor de projeto.

Gestão de portfólio de projetos

Um número crescente de organizações está usando o que é conhecido como gerenciamento de portfólio de projetos (PPM) como um meio de selecionar os projetos certos e, em seguida, usando técnicas de gerenciamento de projetos [70] como o meio para entregar os resultados na forma de benefícios para o desempenho organização pública, privada ou sem fins lucrativos. O PPM é geralmente executado por uma equipe dedicada de gerentes organizados em um Enterprise Project Management Office (PMO) chefiado por um diretor de PMO, geralmente baseado na organização. Assim, o cargo de encarregado do PPM também pode ser designado como chief project officer ou chief technology officer. Nos casos em que as iniciativas estratégicas de uma organização constituem a maior parte do PPM, o chefe do PPM é intitulado como o diretor de iniciativa.

Software de gerenciamento de projeto

O software de gerenciamento de projetos é usado para ajudar a planejar, organizar e gerenciar pools de recursos, desenvolver estimativas de recursos e implementar planos. Dependendo da sofisticação do software, a funcionalidade pode incluir estimativa e planejamento, programação , controle de custos e gerenciamento de orçamento , alocação de recursos , software de colaboração , comunicação , tomada de decisão , fluxo de trabalho , risco , qualidade, documentação e / ou sistemas de administração. [71] [72]

Gerenciamento de projetos Virtual

O gerenciamento de programa virtual (VPM) é o gerenciamento de um projeto feito por uma equipe virtual , embora raramente possa se referir a um projeto implementando um ambiente virtual [73]. Note-se que gerenciar um projeto virtual é fundamentalmente diferente de gerenciar projetos tradicionais, [74 ] combinando preocupações de teletrabalho e colaboração global (cultura, fusos horários, idioma). [75]

Veja também

Referências

  1. ^ (2003). Guia de estudo do PMP Project Management Professional . McGraw-Hill Professional, 2003. ISBN  0-07-223062-2 p.354.
  2. ^ Baratta, Angelo (2006). “A tripla restrição uma tripla ilusão” . PMI . Página visitada em 22 de dezembro de 2020 .
  3. ^ O guia definitivo para gerenciamento de projetos . Nokes, Sebastian. 2ª Ed.n. Londres (Financial Times / Prentice Hall): 2007. ISBN 978-0-273-710am97-4  Erro de parâmetro em {{ ISBN }}: ISBN inválido . 
  4. ^ "O que é gerenciamento de projetos?" . Project Management Institute . Página visitada em 04/06/2014 .
  5. ^ Paul C. Dinsmore e outros (2005) Os projetos certos feitos certo! John Wiley and Sons, 2005. ISBN 0-7879-7113-8 . p.35 e mais. 
  6. ^ Cattani, G .; Ferriani, S .; Frederiksen, L .; Florian, T. (2011). Organização baseada em projetos e gerenciamento estratégico . Avanços em Gestão Estratégica. 28 . Esmeralda. ISBN 978-1780521930.
  7. ^ Dennis Lock (2007) Gerenciamento de projetos (9ª ed.) Gower Publishing, Ltd., 2007. ISBN 0-566-08772-3 
  8. ^ Young-Hoon Kwak (2005). "Uma breve história do gerenciamento de projetos". In: A história do gerenciamento de projetos . Elias G. Carayannis et al. (9 eds), Greenwood Publishing Group, 2005. ISBN 1-56720-506-2 
  9. ^ David I. Cleland , Roland Gareis (2006). Manual de gerenciamento de projeto global . "Capítulo 1:" A evolução da gestão de projetos ". McGraw-Hill Professional, 2006. ISBN 0-07-146045-4 
  10. ^ Martin Stevens (2002). Caminhos de gerenciamento de projetos . Associação para gerenciamento de projetos. APM Publishing Limited, 2002 ISBN 1-903494-01-X p.xxii 
  11. ^ Edward R. Marsh (1975). "O Harmonograma de Karol Adamiecki". In: The Academy of Management Journal . Vol. 18, No. 2 (junho, 1975), p. 358. ( online )
  12. ^ Morgen Witzel (2003). Cinqüenta figuras-chave na administração . Routledge, 2003. ISBN 0-415-36977-0 . p. 96-101. 
  13. ^ David I. Cleland , Roland Gareis (2006). Manual de gerenciamento de projeto global . McGraw-Hill Professional, 2006. ISBN 0-07-146045-4 . p.1-4 afirma: " Foi na década de 1950 que o gerenciamento de projetos foi formalmente reconhecido como uma contribuição distinta decorrente da disciplina de gerenciamento. " 
  14. ^ Malcolm, DG , Roseboom, JH, Clark, CE, & Fazar, W. (1959). " Aplicação de uma técnica para avaliação de programas de pesquisa e desenvolvimento ." Pesquisa operacional, 7 (5), 646-669.
  15. ^ FL Harrison, Dennis Lock (2004). Gerenciamento avançado de projetos: uma abordagem estruturada . Gower Publishing, Ltd., 2004. ISBN 0-566-07822-8 . p.34. 
  16. ^ Saladis, FP (2006). Trazendo o guia PMBOK® à vida. Artigo apresentado no PMI® Global Congress 2006 - América do Norte, Seattle, WA. Newtown Square, PA: Project Management Institute. Disponível em https://www.pmi.org/learning/library/bringing-pmbok-guide-life-practical-8009
  17. ^ "Gerente de construção certificado" . CMAA . Retirado em 23 de novembro de 2013 .
  18. ^ "Certificado em Gerenciamento de Projetos de Biotecnologia" . Universidade de Washington . Retirado em 23 de novembro de 2013 .
  19. ^ Esselink, Bert (2000). Um guia prático para localização . Amsterdã / Filadélfia: John Benjamins Publishing Company. p. 428. ISBN 978-9-027-21956-5.
  20. ^ Mesly, Olivier. (2017). Viabilidade do projeto - Ferramentas para descobrir pontos de vulnerabilidade. New York, NY: Taylor and Francis, CRC Press. 546 páginas. ISBN 9 781498 757911 . 
  21. ^ Cf. The Bridger (blog), "Gerenciamento de projetos: PMP, Prince 2 ou uma variante iterativa ou ágil"
  22. ^ Serra, CEM; Kunc, M. (2014). “Gestão da Realização de Benefícios e sua influência no sucesso dos projetos e na execução das estratégias de negócio” . International Journal of Project Management . 33 (1): 53–66. doi : 10.1016 / j.ijproman.2014.03.011 .
  23. ^ Hass, Kathleen B. (Kitty) (2 de março de 2010). "Gerenciando projetos complexos que são muito grandes, muito longos e muito caros" . PM Times . Recuperado em 27-06-2017 .
  24. ^ Conforto, EC; Salum, F .; Amaral, DC; da Silva, SL; Magnanini de Almeida, L. F (junho de 2014). "O gerenciamento ágil de projetos pode ser adotado por outras indústrias além do desenvolvimento de software?". Diário de gerenciamento de projetos . 45 (3): 21–34. doi : 10.1002 / pmj.21410 . S2CID 110595660 . 
  25. ^ Patel, Himanshu (20 de abril de 2018). "Explicação do modelo em cascata no gerenciamento de projetos" . ItsGuru . Obtido em 20-04-2017 .
  26. ^ Snowden, David J .; Boone, Mary E. (novembro de 2007). "Estrutura de um líder para tomada de decisão" . Harvard Business Review . Recuperado em 27-06-2017 .
  27. ^ "O estudo de pesquisa de Stanford descobre que a engenharia da inovação é um verdadeiro sistema de" inovação revolucionária " . IE News . 20 de junho de 2017 . Recuperado em 11/08/2017 .
  28. ^ Wysocki, Robert K. (2013). Gerenciamento de projeto eficaz: tradicional, adaptativo, extremo (sétima ed.). John Wiley & Sons . ISBN 978-1118729168.
  29. ^ Winston W. Royce (1970). "Gerenciando o desenvolvimento de grandes sistemas de software" Arquivado em 15/03/2016 na Wayback Machine em: Artigos técnicos da Western Electronic Show and Convention (WesCon) de 25 a 28 de agosto de 1970, Los Angeles, EUA.
  30. ^ a b Stellman, Andrew; Greene, Jennifer (2005). Gerenciamento de Projetos de Software Aplicado . O'Reilly Media. ISBN 978-0-596-00948-9. Arquivado do original em 09/02/2015.
  31. ^ McCaffer, Ronald; Harris, Frank (2013). Gestão de construção moderna . Wiley-Blackwell. p. 5. ISBN 978-1118510186. OCLC  834624541 .
  32. ^ Office for Government Commerce (1996) Gerenciando projetos bem-sucedidos com PRINCE2 , p14
  33. ^ OGC - PRINCE2 - Plano de fundo
  34. ^ a b c d e f "Guia de gerenciamento de projetos" (PDF) . VA Escritório de Informação e Tecnologia . 2003. Arquivado do original em 14 de janeiro de 2009. CS1 maint: unfit URL (link)
  35. ^ a b c PMI (2010). Um Guia para o Conjunto de Conhecimentos em Gerenciamento de Projetos, p.27-35
  36. ^ Peter Nathan, Gerald Everett Jones (2003). Certificação PMP para manequins . p.63.
  37. ^ Harold Kerzner (2003). Gerenciamento de projetos: uma abordagem de sistemas para planejamento, programação e controle (8ª ed.). Wiley. ISBN 0-471-22577-0.
  38. ^ a b James P. Lewis (2000). Referência de mesa do gerente de projeto:: um guia abrangente para planejamento, programação, avaliação e sistemas de projetos. p.185
  39. ^ Eccles, Robert G. (1981). “A quase-empresa na indústria da construção” . Journal of Economic Behavior & Organization . 2 (4): 335–357. doi : 10.1016 / 0167-2681 (81) 90013-5 . ISSN 0167-2681 . 
  40. ^ Davies, Andrew; Hobday, Michael (2005). O negócio de projetos: gestão da inovação em produtos e sistemas complexos . Cambridge University Press. ISBN 978-0-521-84328-7.
  41. ^ Gann, David; Salter, Ammon; Dodgson, Mark; Philips, Nelson (2012). “Por dentro do mundo do barão do projeto” . Revisão da gestão do MIT Sloan . 53 (3): 63–71. ISSN 1532-9194 . 
  42. ^ Meng, Xianhai (2012). “O efeito da gestão do relacionamento no desempenho do projeto na construção” . International Journal of Project Management . 30 (2): 188–198. doi : 10.1016 / j.ijproman.2011.04.002 .
  43. ^ Oliveira, Nuno; Lumineau, Fabrice (2017). "Como as trajetórias de coordenação influenciam o desempenho de redes de projetos interorganizacionais" . Ciência da Organização . 28 (6): 1029–1060. doi : 10.1287 / orsc.2017.1151 . ISSN 1047-7039 . 
  44. ^ Cohen Kashi S., Rozenes S. & Ben-Gal, I. (2016). "Monitoramento do gerenciamento de projetos com base na entropia de duração esperada" (PDF) . Em Entropy 2020, 22, 905. CS1 maint: multiple names: authors list (link)
  45. ^ Jörg Becker, Martin Kugeler, Michael Rosemann (2003). Gestão de processos: um guia para o desenho de processos de negócios. ISBN 978-3-540-43499-3 . p.27. 
  46. ^ Bernhard Schlagheck (2000). Objektorientierte Referenzmodelle für das Prozess- und Projektcontrolling. Grundlagen - Konstruktionen - Anwendungsmöglichkeiten. ISBN 978-3-8244-7162-1 . p.131. 
  47. ^ Josef E. Riedl (1990). Projekt - Controle em Forschung und Entwicklung. ISBN 978-3-540-51963-8 . p.99. 
  48. ^ Steinle, Bruch, Lawa (1995). Gerenciamento de projetos. FAZ Verlagsbereich Wirtschaftsbücher. p.136-143
  49. ^ Cynthia Snyder, Frank Parth (2006). Introdução ao gerenciamento de projetos de TI. p.393-397
  50. ^ Abdou, Saed M; Yong, Kuan; Othman, Mohammed (2016). "Influência da complexidade do projeto no desempenho da gestão do projeto - a perspectiva da Malásia" . MATEC Web of Conferences . 66 : 00065. doi : 10.1051 / matecconf / 20166600065 . ISSN 2261-236X . 
  51. ^ Morcov, Stefan; Pintelon, Liliane; Kusters, Rob J. (2020). "Definições, características e medidas de complexidade de projetos de TI - uma revisão sistemática da literatura" (PDF) . Revista Internacional de Sistemas de Informação e Gerenciamento de Projetos . 8 (2): 5–21. doi : 10.12821 / ijispm080201 .
  52. ^ a b Marle, Franck; Vidal, Ludovic ‐ Alexandre (2016). Gerenciando Projetos Complexos de Alto Risco - Um Guia para Gerenciamento Básico e Avançado de Projetos . Londres: Springer-Verlag.
  53. ^ Vidal, Ludovic-Alexandre; Marle, Franck; Bocquet, Jean-Claude (2011). "Medindo a complexidade do projeto usando o Processo de Hierarquia Analítica". International Journal of Project Management . 29 : 718–727.
  54. ^ Vidal, Ludovic-Alexandre; Marle, Franck (2008). "Compreendendo a complexidade do projeto: implicações no gerenciamento de projetos" (PDF) . Kybernetes . 37 (8): 1094–1110. doi : 10.1108 / 03684920810884928 .
  55. ^ Baccarini, D. (1996). “O conceito de complexidade do projeto, uma revisão”. International Journal of Project Management . 14 (4): 201–204.
  56. ^ Snowden, David J .; Boone, Mary E. (2007). "Estrutura de um líder para tomada de decisão" . Harvard Business Review . 85 (11): 68–76.CS1 maint: multiple names: authors list (link)
  57. ^ Maurer, Maik (2017). Gerenciamento da complexidade em projeto de engenharia - uma cartilha . Berlim, Heidelberg: Springer.
  58. ^ Kurtz, CF; Snowden, David J. (2003). “A nova dinâmica da estratégia: Sense-making num mundo complexo e complicado”. IBM Systems Journal . 42 (3): 462–483. doi : 10.1147 / sj.423.0462 .CS1 maint: multiple names: authors list (link)
  59. ^ G., Morris, Peter W. (1994). A gestão de projetos . Londres: T. Telford. p. 317. ISBN 978-0727725936. OCLC  30437274 .
  60. ^ Manual Gower de pessoas em gerenciamento de projetos . Lock, Dennis., Scott, Lindsay, 1974-. Farnham, Surrey: Gower Publishing. 2013. p. 398. ISBN 978-1409437857. OCLC  855019788 .CS1 maint: others (link)
  61. ^ "PMOs" . www.theprojectmanager.co.za . Obtido em 01/03/2018 .
  62. ^ Comissão, serviço público australiano. "Quadro APS para estruturas de gerenciamento ideais" . Obtido em 01/03/2018 .
  63. ^ Morcov, Stefan; Pintelon, Liliane; Kusters, Rob J. (2020). "Gerenciamento da complexidade de projetos de TI com base em fontes e efeitos: positivos, apropriados e negativos" (PDF) . Proceedings da Academia Romena - Série A . 21 (4): 329–336.
  64. ^ Bannerman, PL (2008). Definindo o sucesso do projeto: uma estrutura multinível. Artigo apresentado na Conferência de Pesquisa PMI®: Definindo o Futuro do Gerenciamento de Projetos, Varsóvia, Polônia. Newtown Square, PA: Project Management Institute. Disponível em https://www.pmi.org/learning/library/defining-project-success-multilevel-framework-7096
  65. ^ Emanuel Camilleri, sucesso do projeto: Fatores críticos e comportamentos, Gower Publishing, Ltd., 2011
  66. ^ "DoDD 5000.01" (PDF) . Departamento de Defesa dos Estados Unidos . Página visitada em 20 de novembro de 2007 .
  67. ^ a b NASA NPR 9501.2D . 23 de maio de 2001.
  68. ^ ISO / IEC / IEEE 16326-2009 - Engenharia de Sistemas e Software - Processos de Ciclo de Vida - Gerenciamento de Projetos. Dezembro de 2009. DOI: 10.1109 / IEEESTD.2009.5372630. ISBN 978-0-7381-6116-7 
  69. ^ Linha de base de competência individual para gerenciamento de projetos, programas e portfólio (PDF) . International Project Management Association (IPMA). 2015. ISBN  978-94-92338-01-3.
  70. ^ Albert Hamilton (2004). Manual de procedimentos de gerenciamento de projetos. TTL Publishing, Ltd. ISBN 0-7277-3258-7 
  71. ^ PMBOK 4h Ed . 2008. p. 443. ISBN 978-1933890517.
  72. ^ Tom Kendrick. O Kit de ferramentas de gerenciamento de projetos: 100 dicas e técnicas para fazer o trabalho da maneira certa , terceira edição. Livros AMACOM, 2013 ISBN 9780814433454 
  73. ^ Curlee, Wanda (2011). O Virtual Project Management Office: Melhores práticas, métodos comprovados .
  74. ^ Khazanchi, Deepak (2005). Padrões de gerenciamento eficaz de projetos em projetos virtuais: um estudo exploratório . Instituto de Gerenciamento de Projetos. ISBN 9781930699830. Arquivado do original em 23/10/2013 . Página visitada em 2013-10-22 .
  75. ^ Velagapudi, Mridula (13 de abril de 2012). "Por que você não pode evitar o Virtual Project Management 2012 em diante" .

Ligações externas