Qual a Diferença entre Padrões e Metodologias de Gerenciamento de Projetos?

1Qual a Diferença entre Padrões e Metodologias de Gerenciamento de Projetos?

Autor: Carlos Magno da Silva Xavier (Doutor, PMP)

Sócio-Diretor da Beware Consultoria e Treinamento

Professor de MBAs da FGV, UFRJ e Fundação Dom Cabral

magno@beware.com.br

Temos visto no Brasil, nos últimos 15 anos, uma busca das Organizações em melhorar suas práticas de gestão de projetos, principalmente em razão do aumento da competição entre as empresas e da cobrança por maior eficiência e eficácia em suas iniciativas.

Porém, existe uma confusão entre o que é um padrão, uma metodologia de gerenciamento de projetos e uma metodologia de desenvolvimento de produtos. Por exemplo, o PMBOK® Guide e o SCRUM são metodologias de gerenciamento de projetos?

Este texto pretende apresentar a minha interpretação acerca desse assunto, citando alguns padrões e metodologias mais utilizados no apoio ao gerenciamento de projetos.

Padrões

2Em Administração e Qualidade, padrão é uma norma técnica, ou seja, um "documento aprovado por um organismo reconhecido que provê, pelo uso comum e repetitivo, regras, diretrizes ou características de produtos, processos ou serviços cuja obediência não é obrigatória”[1]. Alguns exemplos de padrões: ISO (International Standards for Organization) e ABNT (Associação Brasileira de Normas Técnicas). Padrão não deve ser confundido com modelo de maturidade, tais como OPM3 (Organizational Project Management Maturity Model), CMMI (Capability Maturity Model Integration) e MPS.BR (Melhoria de Processo do Software Brasileiro).

No Brasil, a maior referência utilizada para as práticas de gerenciamento de projetos é o Project Management Institute (PMI)[2]. Suas publicações de diretrizes e normas são preparadas através de um processo de desenvolvimento de normas de consenso. Esse processo reúne pessoas voluntárias e/ou busca os pontos de vista de pessoas interessadas nos tópicos cobertos por cada publicação. Os seguintes padrões (standards) foram desenvolvidos pelo PMI até a data de publicação deste texto:

3A Guide to the Project Management Body of Knowledge (PMBOK® Guide)

 

 

 

4Construction Extension to the PMBOK® Guide

 

 

 

5Government Extension to the PMBOK® Guide

 

 

 

6The Standard for Program Management

 

 

 

7The Standard for Portfolio Management

 

 

 

8Practice Standard for Project Risk Management

 

 

 

 

9Practice Standard for Earned Value Management

 

 

 

10Practice Standard for Project Configuration Management

 

 

 

 

11Practice Standard for Work Breakdown Structures

 

 

 

12Practice Standard for Scheduling

 

 

 

13Practice Standard for Project Estimating

 

 

 

14Project Manager Competency Development Framework

 

 

 

15Organizational Project Management Maturity Model (OPM3®)—Third Edition

 

 

 

O PMI também disponibiliza os seguintes guias:

16

 

17

 

 

18

19

 

 

 

 

 

20

 

Desta forma, o PMBOK® Guide é um padrão e não uma metodologia.

Metodologias

Segundo o Dicionário Houaiss, metodologia “é o ramo da lógica que se ocupa dos métodos de diferentes ciências” e método “é um procedimento, técnica ou meio de fazer alguma coisa”, assim como “uma ordem, lógica ou sistema que regula determinada atividade”. Existe uma diferença entre metodologia de desenvolvimento de um produto ou serviço e a metodologia para o gerenciamento do projeto que vai fazer esse desenvolvimento. A primeira trata do ciclo de vida para gerar o produto ou serviço (escopo do produto) e a segunda é responsável por iniciar, planejar, executar, monitorar, controlar e encerrar esse projeto, levando em consideração o escopo (do projeto), tempo, custo, risco etc.

Metodologias de Desenvolvimento de Produto / Serviço

Dependendo do produto ou serviço a ser desenvolvido, podemos utilizar uma metodologia de desenvolvimento, também conhecida pela sigla SDLC (System Development Life Cycle, System Design Life Cycle ou, no caso de desenvolvimento de sistemas, Software Development Life Cycle). Alguns exemplos são:

  • Rational Unified Process – é um processo interativo de desenvolvimento de software (JACOBSON, 1999);
  • Agile Unified Process – é uma simplificação do RUP feita por Scott Ambler[3];
  • Scrum - o conceito de scrum como método de trabalho de desenvolvimento de produtos foi definido, em 1986, num estudo publicado por Hirotaka Takeuchi e Ikujiro Nonaka na Harvard Business Review (TAKEUCHI, 1986). Eles associaram a formação de equipes eficazes à forma SCRUM do Rugby. Depois disso, a indústria de software se apropriou da ferramenta, tendo como principais mentores Ken Schwaber e Jeff Sutherland. Segundo SCHWABER (2011), Scrum vem sendo utilizado para o desenvolvimento de produtos complexos desde o início dos anos 90, empregando uma abordagem iterativa e incremental para otimizar a previsibilidade e controlar riscos. Três pilares sustentam cada implementação de controle de processos empíricos: transparência; inspeção e adaptação. O coração do Scrum é a Sprint, que é uma iteração de um mês ou menos, de duração consistente com o esforço de desenvolvimento.
  • Extreme Programing (XP) – para TELES (2004) é um processo de desenvolvimento que possibilita a criação de software de alta qualidade, de maneira ágil, econômica e flexível.
  • Lean Construction – segundo PANDOLFO (2006) é uma filosofia de gestão da produção, voltada a obras civis, surgida a partir do trabalho do pesquisador finlandês Lauri Koskela em 1992, adaptando as técnicas e ferramentas desenvolvidas com sucesso no Sistema Toyota de Produção (Lean Production).
  • Product Quality Advanced Planning (APQP)[4] - é um processo desenvolvido no final dos anos 80 por uma comissão de experts das três maiores indústrias automobilísticas: Ford, General Motors e Chrysler. Essa comissão investiu cinco anos para analisar o então corrente estado de desenvolvimento e produção automotiva nos Estados Unidos, Europa e especialmente no Japão.
  • Stage-Gates / FEL – este modelo, também conhecido como phase-gates, é uma técnica de gerenciamento de projetos na qual um projeto é dividido em fases, separadas por portões. Ele foi desenvolvido e primeiramente sugerido por Robert G. Cooper em 1986[5]. É muito utilizado em projetos de megaempreendimentos, tecnicamente denominados de projetos de capital. Ao final de cada fase do projeto existe um portão de decisão (gate) onde os decisores podem considerar continuar ou não com o projeto. Ele é conhecido também como o modelo da Independent Project Analysis (IPA)[6] e como FEL (Front End Loading). A figura 1 apresenta um exemplo de divisão de um projeto em fases.21Figura 1 – As fases de uma Metodologia FEL
Fonte: Manual do Programa de Desenvolvimento e Execução de Projetos do E&P (PRODEP) da Petrobras – versão 2004

Desta forma, o SCRUM é um método para o desenvolvimento de um produto e não uma metodologia de gerenciamento de projetos.

Metodologias de Gerenciamento de Projetos

Segundo KERZNER (2001), o alcance da excelência em gerenciamento de projetos não é possível sem um processo repetitivo que possa ser utilizado em cada projeto. Esse processo repetitivo é a metodologia de gerenciamento de projetos. Para CHARVAT (2003), “uma metodologia é um conjunto de orientações e princípios que podem ser adaptados e aplicados em uma situação específica. Em ambiente de projetos essa orientação é uma lista de coisas a fazer. Uma metodologia pode também ter uma abordagem específica, modelos, formulários e também check lists, usados durante o ciclo de vida do projeto". Desta forma, uma metodologia de gerenciamento de projetos é um conjunto de processos, métodos e ferramentas para o alcance dos objetivos do projeto. Ela deve prover um roteiro (roadmap) para o gerenciamento do projeto. Equipes que não compartilham uma metodologia tendem a ser ineficientes.

Algumas vezes vemos alguém dizer ou escrever que usa a “Metodologia do PMI” ou a “Metodologia do Guia PMBOK®”. Na realidade, o PMI ou até mesmo o Guia PMBOK® não apresentam uma metodologia. O Guia aborda somente “o que” é necessário para o gerenciamento de projetos, sem entrar no mérito de “como” esses processos deveriam ser realizados e em que sequência. Por isso enquadramos, anteriormente neste capítulo, o Guia como um padrão.

Não existe uma metodologia que possa ser utilizada em qualquer empresa ou projeto. Essa percepção fica clara quando analisamos um dos resultados do “Estudo de Benchmarking em Gerenciamento de Projetos”, realizado em 2013 no Brasil, que indicou que 49% das empresas consultadas informaram que pretendiam, nos próximos 12 meses, rever ou desenvolver uma metodologia de gerenciamento de projetos, o que pode ser visto na figura 2. Se existisse uma metodologia universal, não seria necessário esse esforço das Organizações.22Figura 2 - Iniciativas em gerenciamento de projetos que as organizações pretendem adotar nos próximos 12 meses

Fonte: Estudo de Benchmarking em Gerenciamento de Projetos 2013, disponível em www.pmsurvey.org.

Uma metodologia é, portanto, uma adaptação, à realidade dos projetos da Organização, das práticas existentes no mercado, tanto das propostas pela literatura como daquelas vivenciadas pelos profissionais de gerenciamento. Essa adaptação deve ser criteriosa de forma a que, em uma análise de custo-benefício, compense o esforço de gerenciamento em relação aos correspondentes resultados esperados. No PMBOK® Guide, por exemplo, dos 47 (quarenta e sete) processos de gerenciamento de projetos, 24 (vinte e quatro) são de planejamento, com 26 (vinte e seis) documentos de saída desses processos. Imagine se para planejarmos o projeto de um churrasco no final de semana tivéssemos de fazer todos esses documentos? Esse exemplo, embora simplista, elucida a necessidade de adaptarmos as práticas existentes para cada Organização / projeto.

O que deve ter uma metodologia?

 Algumas das características que uma metodologia de gerenciamento de projetos deve ter são (Kerzner, 2001):

  • Um nível recomendado de detalhes;
  • Uso de modelos;
  • Técnicas padronizadas de planejamento, programação e controle;
  • Formato padronizado de relato de desempenho;
  • Flexibilidade na aplicação nos projetos;
  • Flexibilidade para melhorias, quando necessário;
  • Facilidade de entendimento e aplicação;
  • Ser aceita e aplicada em toda a Organização.

Para o gerenciamento de projetos, com a aplicação de conhecimentos, habilidades, ferramentas e técnicas às atividades do projeto, a fim de atender ao propósito para o qual ele está sendo executado, o Guia PMBOK® (PMI, 2013) propõe dez áreas de conhecimento: escopo, tempo, custo, qualidade, recursos humanos, comunicações, risco, aquisições, stakeholders e integração (responsável pela consistência entre as áreas), o que pode ser visualizado na figura 3.23

Figura 3 – As áreas de conhecimento do gerenciamento de projetos
Fonte: Xavier (2014), página 7

Ainda como resultado do “Estudo de Benchmarking em Gerenciamento de Projetos”, verificou-se que as Organizações focam mais as suas metodologias em prazo, escopo e custo, como pode ser visto na figura 4.

24Figura 4 - Aspectos considerados na Metodologia de Gerenciamento de Projetos
Fonte: Estudo de Benchmarking em Gerenciamento de Projetos 2013, disponível em www.pmsurvey.org.

 

25

Figura 5 - Problemas que ocorrem com mais frequência nos projetos da Organização
Fonte: Estudo de Benchmarking em Gerenciamento de Projetos 2013, disponível em www.pmsurvey.org.

O contexto do gerenciamento de projetos abrange também o gerenciamento de portfólio e programas. Na figura 6 pode ser verificado que um projeto inicia, normalmente, com a elaboração de uma proposta, que demanda um planejamento preliminar do projeto e a verificação da sua viabilidade, em relação à parte técnica, econômica e financeira.

26Figura 6 – O Contexto do Gerenciamento de Projetos
Fonte: Adaptado da Figura 3-1 do PMBOK® Guide (PMI, 2013)

Aprovado o projeto, ele deve ser formalmente autorizado (iniciação) e detalhado o seu planejamento para a execução. Ele entra então no ciclo PDCA (Plan, Do, Check e Act) de melhoramento contínuo. Também conhecido como ciclo de Shewhart ou ciclo de Deming, foi introduzido no Japão por Deming após a 2ª guerra, tendo sido idealizado por Shewhart na década de 20 [7]. Checar ou monitorar o trabalho do projeto significa observar, coletar, disseminar e avaliar informações a respeito do desempenho do projeto a cada período de tempo. O Act é para tomar uma decisão em razão de desvios em relação ao planejado. Após a entrega dos produtos e serviços previstos no escopo, está na hora de encerrar o projeto.

Desta forma, para ficar prática a sua utilização, uma metodologia deve ter um roadmap que descreva a utilização dos processos de gerenciamento de projetos em termos da integração entre os processos, das interações dentro deles e dos objetivos a que atendem. Esses processos podem ser agregados, por exemplo, nos “grupos de processos de gerenciamento de projetos”: Iniciação; Planejamento; Execução; Monitoramento e Controle; e Encerramento.

A carteira deve ser acompanhada, de maneira que os seus projetos possam ser monitorados e controlados, de forma corporativa, assim como, após o encerramento, ser verificado se eles alcançaram os resultados para os quais eles foram autorizados. Para Dinsmore (2006), “precisamos fazer certo a combinação certa dos projetos certos”.

Assim sendo, podemos ter metodologias para gerenciamento de projetos, programas e portfólio.

Algumas Metodologias existentes no mercado

Como subsídio para a redação deste tópico do capítulo, o autor fez uma pesquisa em algumas listas de discussão de profissionais de gerenciamento de projetos existentes na Internet, tendo sido colocada a seguinte pergunta: “A metodologia de gerenciamento de projetos utilizada em seu Setor / Organização foi desenvolvida com base em alguma metodologia específica existente na literatura / mercado? ”.

Responderam à pesquisa 645 pessoas. Daqueles que afirmaram utilizar uma metodologia, 73% responderam que a metodologia não foi baseada em nenhuma específica do mercado. Vale ressaltar que 120 dos que escolheram a opção “Utilizamos outra metodologia como base”, especificaram na realidade um padrão, um modelo de maturidade ou uma metodologia de desenvolvimento de produto, o que mostra como o conceito de metodologia tem interpretações diversas no mercado. As metodologias mais citadas na pesquisa estão, em ordem alfabética, comentadas a seguir.

Method 123 Project Management Methodology[8]

 A Method 123 Project Management Methodology (MPMM™) é uma metodologia comercial baseada no PMBOK® e no Prince2™, possuindo três versões: Professional, Standard e Educational. Essa metodologia foi encapsulada em um software que permite navegar rapidamente pelos processos e acessar os modelos.

Methodware®[9]

27Essa metodologia foi divulgada em 2006 no livro “Metodologia de Gerenciamento de Projetos – Methodware®”, que está atualmente em sua 3ª edição (Xavier, 2013). Em 2010 ele foi premiado como o “Melhor Livro Brasileiro de Gerenciamento de Projetos da Década”. A premiação ocorreu no 8º Encontro Nacional de Profissionais de Gerenciamento de Projetos, promovido pelo PMI-Rio. Mais de mil profissionais de gerenciamento de projetos participaram da escolha. A metodologia possui 31 processos organizados nos Grupos de Processos: Iniciação, Planejamento, Execução, Monitoramento e Controle e Encerramento do Projeto. Possui 36 modelos de documentos e um exemplo de Plano do Projeto.

A metodologia Methodware® possui uma simplificação, de utilização prática, para estudantes e gerentes de projetos de pequeno e médio porte: a Basic Methodware®. Ela possui 13 processos organizados em: Iniciar, Planejar (Plan), Executar (Do), Monitorar e Controlar (Check and Act) e Encerrar, utilizando o cliclo PDCA. Em abril de 2011 foi lançado o livro “Metodologia Simplificada de Gerenciamento de Projetos – Basic Methodware® (Xavier, 2011).

trainee 5

PRINCE2™ (Ribeiro, 2011)

PRINCE2 é uma marca registrada do OGC (The Office Government Commerce) e significa Projeto em Ambiente Controlado (Project IN Controlled Enviroment). A primeira versão do PRINCE2 foi lançada em 1996, porém sua história começa 1975 com o PROMPT II, que também era um método estruturado para gerenciamento de projetos, que evoluiu para o PRINCE em 1989 até chegar à denominação atual PRINCE2 em 1996. Atualmente o PRINCE2 está na sua 5ª edição, esta última lançada em 2009.

A estrutura do método PRINCE2 é composta de princípios, temas, processos e leva sempre em consideração o ambiente do projeto para que o método possa ser adaptado (Tayloring). Isto significa que a tenacidade de aplicação do método deve ser adequada às características do projeto. De forma geral, o método PRINCE2 é uma estrutura sistemática com processos, papéis e responsabilidades bem definidos que visam garantir o gerenciamento organizado do projeto desde a sua concepção até o encerramento.

Os princípios formam a base do PRINCE2 e a não aplicação destes descaracteriza o uso da metodologia, sendo, portanto, itens obrigatórios. Ter uma justificativa para o projeto, aprender com experiências passadas, ter papéis e responsabilidades bem definidos, gerenciar o projeto por estágios, estabelecer tolerâncias e assim poder gerenciar por exceção, manter sempre o foco no produto e adaptar o método de acordo com as características do projeto são questões imprescindíveis para que o projeto seja gerenciado de acordo com a metodologia PRINCE2.  Se estes sete princípios não forem aplicados no projeto, o método não está sendo aplicado.

Os temas PRINCE2 descrevem os aspectos de gerenciamento que devem ser monitorados e aplicados conforme característica do projeto. Um projeto PRINCE2 só existe caso seja viável e traga um ou mais benefícios para a organização e, por esta razão, todo projeto deve ter um Business Case que é um dos sete temas PRINCE2. Outros três temas que merecem destaque são: organização, que diz respeito à estrutura organizacional que um projeto PRINCE2 tem que ter; qualidade, que tem foco na qualidade dos produtos dos produtos do projeto, tendo forte interação com o princípio foco no produto e com as técnicas, estas únicas na metodologia, Planejamento Baseado em Produto e Revisão da Qualidade; planos, no método PRINCE2 há planos no nível de projeto, de estágios e de time do projeto. Os demais temas do método são riscos e mudança, que estão relacionados respectivamente ao gerenciamento de riscos e de mudanças, e progresso que está relacionado ao monitoramento do andamento e desempenho do projeto.

Os processos PRINCE2 correspondem ao conjunto de atividades relacionadas para conduzir o projeto ao seu objetivo de forma organizada e controlada. Eles são integrados e começam a ser executados antes mesmo do projeto nascer, ou seja, desde o início do ciclo de vida ou jornada PRINCE2. Esta jornada tem como etapas: pré-projeto, estágio inicial, subsequentes estágios de entregas e estágio final de entregas.

Os processos do PRINCE2 são:

  • Viabilizar o projeto (Starting up a Project) – visa verificar a viabilidade do projeto para a organização.
  • Dirigir o projeto – processo de responsabilidade do Comitê de Direção do Projeto que deve tomar decisões estratégicas e fornecer condições favoráveis para o desenvolvimento do projeto.
  • Iniciar o projeto – foco em reunir informações necessárias, tais como objetivo, escopo, benefícios, custo etc. para iniciar o projeto.
  • Gerenciar fronteiras entre estágios – foco em reunir informações necessárias do estágio atual e do próximo estágio do projeto para assegurar as tomadas de decisão do Comitê de Direção do Projeto quanto à continuidade, interrupção, encerramento, cancelamento do projeto etc.
  • Controlar estágios – conjunto de atividades para controlar e monitorar os estágios definidos para o projeto.
  • Gerenciar entrega do produto – visa garantir que os produtos esperados sejam desenvolvidos e entregues conforme planejado e atributos de qualidade.
  • Encerrar o projeto – atividades destinadas a garantir o encerramento controlado do projeto.29

O método PRINCE2 não é rico em técnicas, tendo apenas duas inseridas em seu contexto. A técnica de Planejamento Baseado em Produto é uma característica-chave do método e seu uso é obrigatório. Esta técnica consiste, basicamente, em quatro etapas que devem ser executadas na seguinte ordem: descrição do produto final do projeto, criação da estrutura analítica do produto (similar a uma estrutura analítica de trabalho), descrição dos produtos e criação do diagrama de fluxo de produtos. A outra técnica da metodologia é revisão da qualidade.

Apesar do PRINCE2 ser considerado o método de gerenciamento de projetos mais utilizado no mundo, sendo utilizado em mais de 20.000 organizações e presente em mais de 150 países, a maioria dos materiais bibliográficos estão escrito no idioma inglês e podem ser adquiridos nos principais sítios de comércio eletrônico de livros dos Estados Unidos e de países da Europa.

Ten Step[10] 

A metodologia TenStep Processo de Gerenciamento de Projetos® foi projetada para ser aplicada a todos os tipos de projetos, desde a construção de uma casa, ou mesmo um circuito eletrônico, ou um software. O processo da Metodologia TenStep também é compatível com todos os tipos de metodologias utilizadas no ciclo de vida dos projetos.

 Zopp (Marco Lógico)[11]

A metodologia ZOPP, do alemão "Ziel Orientierte Projekt Planung" - Planejamento de Projetos Orientado por Objetivos - foi criada pela Agência Alemã de Cooperação Técnica (GTZ), com sede em Escborn, na Alemanha, entre as décadas de 70 e 80. Com base numa metodologia criada e adotada pela USAID (USA), ao início dos anos 70, o "Logical Framework Approach" (LFA), a GTZ introduziu a participação dos envolvidos como premissa básica do planejamento de projetos.

A ZOPP proporciona a possibilidade de um acompanhamento total do projeto (planejamento, implementação, desenvolvimento e monitoramento) que se divide em quatro etapas:

1ª etapa: Análise do projeto

2ª etapa: Concepção do plano do Projeto

3ª etapa: Execução do Projeto

4ª etapa: Monitoramento e Avaliação

 A importância da adaptação

Você já deve ter se perguntado até que ponto adotar uma metodologia de gerenciamento de projetos não iria “engessar” ou “burocratizar” o desenvolvimento de projetos em sua empresa e se esse não seria mais um dos projetos de padronização que tiveram fracasso em sua empresa.

Segundo Xavier (2011), o fato de adotarmos uma metodologia não quer dizer que ela deva ser aplicada da mesma maneira em todos os projetos da organização. Dependendo da tipicidade e complexidade, a equipe do projeto irá dispender mais ou menos esforço em seu gerenciamento. O gerente do projeto, com a colaboração de sua equipe, é o responsável pela determinação do grau adequado de rigor a ser usado em cada processo de gerenciamento, para um específico projeto, atendendo ao mínimo previsto na Política De Gerenciamento de Projetos da Organização.

Como em uma Organização nos deparamos com uma diversidade de tipos e portes de projetos, não podemos exigir que todos os projetos executem os mesmos processos e gerem os mesmos documentos).

Assim sendo, devemos classificar os projetos de forma a associá-los à metodologia desenvolvida. A figura 7 é uma orientação para o enquadramento de projetos, podendo, no entanto, serem utilizados também outros critérios como importância estratégica, transversalidade, complexidade tecnológica etc.

30

Figura 7 – Classificação de Projetos de acordo com orçamento e prazo
Fonte: (Xavier, 2013)

Devemos em seguida associar os tipos de projetos aos documentos da metodologia. A tabela 1 apresenta um exemplo dessa associação. Vale a pena ressaltar que uma ou mais categorias podem até serem dispensadas de seguir a metodologia, ficando a cargo do gerente do projeto decidir que instrumentos utilizar no gerenciamento, como exemplificado na categoria 6 da tabela.

31

Tabela 1 – Documentos X Categoria de Projetos
Fonte: (Xavier, 2013)

Conclusão

Vimos que o gerenciamento de projetos é uma área de conhecimento que tem sido demandada cada vez com mais intensidade nos últimos anos. A atualização constante, através da participação em cursos e da leitura de livros e artigos, é fator crítico para aqueles que pretendem ter sucesso nessa área. Porém, não basta frequentar bancos escolares, ler diversos materiais sobre o assunto, ter vários anos de experiência, se o profissional não possuir a capacidade de adaptar todo esse conhecimento à realidade de cada projeto. Ao fazer essa adaptação estaremos copiando autores, professores, outros gerentes, mas é necessário que essa cópia seja original, no sentido de obedecer às peculiaridades de cada situação.

Finalizamos com um comentário do Kerzner (2001): “São as pessoas e não as metodologias que gerenciam projetos. Uma metodologia não é mais que um pedaço de papel com instruções. O que transforma esse pedaço de papel em metodologia de sucesso é a forma como a Organização aceita e aplica a metodologia”.

Notas

[1] http://pt.wikipedia.org/wiki

[2] www.pmi.org

[3] http://www.ambysoft.com/unifiedprocess/agileUP.html

[4]  http://www.apqp.com.br

[5] http://en.wikipedia.org/wiki/Stage-gate_model

[6] http://www.ipaglobal.com

[7] http://pt.wikipedia.org/wiki/Ciclo_pdca

[8] www.mpmm.com

[9] http://www.beware.com.br/methodware/

[10] www.tenstep.com.br

[11] http://www.cchla.ufrn.br/rmnatal/relatorio/prac11.pdf

 

dez mandamentos 4Carlos Magno da Silva Xavier (Doutor, PMP) – magno@beware.com.br

Diretor da Beware Consultoria e Treinamento (www.beware.com.br), eleito em 2010 uma das cinco personalidades brasileiras da década na área de gerenciamento de projetos. Autor/coautor de 19 livros, professor de MBAs da FGV, UFRJ e Fundação Dom Cabral e consultor de diversas empresas.

Voltar para Artigos.

> Baixar E-books Gratuitos.

> Conhecer Os Serviços da Beware.

Bibliografia Principal

  • OGC, Office of Government Commerce. Gerenciando Projetos de Sucesso com Prince2TM. London, 2011.
  • PMI, Project Management Institute (Editor). Um Guia do Conjunto de Conhecimentos do Gerenciamento de Projetos – Tradução oficial para o português do PMBOK (Project Management Body of Knowledge) Guide – PMI, 2013
  • Xavier, Carlos Magno da Silva e outros. “Metodologia de Gerenciamento de projetos – Methodware®” - Brasport – 3a edição - 2014.
  • Xavier, Carlos Magno da Silva e Luiz Fernando da Silva Xavier - “Metodologia Simplificada de Gerenciamento de Projetos – Basic Methodware®” - Brasport – 2011.

Bibliografia Complementar

  • ALMEIDA, Norberto de Oliveira. Gerenciamento de Portfólio. Rio de Janeiro, Brasport, 2011.
  • BOOG, Gustavo & Magdalena. Manual de gestão de pessoas e equipes. 1ª edição – Editora: Gente, São Paulo, 2002.
  • CHARVAT, Jason. Project Management Methodologies. John Wiley & Sons, NJ, 2003.
  • DINSMORE, Paul e Terence Cooke-Davies. Right Projects Done Right. John Wiley & Sons, 2006.
  • JACOBSON, Ivar, Grady Booch, and James Rumbaugh. The Unified Software Development Process, 1999.
  • KERZNER, Harold. Project Management: A system approach to planning scheduling and controlling. John Wiley & Sons, 7ª edição, 2001.
  • PANDOLFO, Adalberto, Juliana Kurek, Luciana Brandli, Luciana Pandolfo. Aplicação dos princípios lean ao setor de edificações: construção enxuta uma abordagem prática. UPF Editora, 2006.
  • RIBEIRO, Robériton Luís Oliveira. Gerenciando Projetos com PRINCE2. Rio de Janeiro: Brasport, 2011.
  • SCHWABER, Ken e Jeff Sutherland. Scrum Guide 2010. Versão em português, baixada de scrum.org em 26/07/2011.

× Como podemos ajudar?