Menu
Esqueceu a senha? Fazer cadastro

Vencedores Prêmio Projeto e PMO do Ano 2014

Em sua sétima edição a cerimônia de premiação ocorreu junto ao Congresso Brasileiro de Gerenciamento de Projetos realizado pelo PMI-SP no dia 24/Novembro de 2014, no WTC em São Paulo/SP.

Nossos sinceros parabéns a todos os finalistas e vencedores desta edição 2014 do Prêmio Projeto e PMO do Ano!

Abaixo o resultado da premiação.

 

Projeto do Ano:

VENCEDOR PROJETO DO ANO: HP Brasil / Rodrigo Caixeta; Fabiano Duarte
Projeto CTMM – NOVO DATA CENTER Banco ITAU-UNIBANCO

RodrigoCaixeta_HP_Itau_Premiação 2014 - WEB-160

FINALISTA: Samarco Mineração / Maury de Souza Junior

Projeto: Quarta PelotizaçãoMaury_Samarco_Premiação 2014 - WEB-169

FINALISTA: Light Serviços de Eletricidade / Esdras Eliwan Martins Leite / Paulo Bicalho; Antônio Raad
Projeto: Centro de Demonstração em Eficiência Energética e Smart Grid – Circuito Cidade Inteligente

Esdras_Light_Premiação 2014 - WEB-165

 

Projeto Inovador do Ano: 

VENCEDOR PROJETO INOVADOR: Governo do Estado do Espírito Santo / Joseane Zoghbi / Tyago Hoffmann
Programa Reconstrução ES Pós-Desastre

joseane_Gov_ES_Premiação 2014 - WEB-117

 

Projeto Acadêmico do Ano:

VENCEDOR PROJETO ACADÊMICO: Carlos Magno da Silva Xavier / Universidade Nacional de Rosário
Tese: As Balas de Prata no Gerenciamento de Projetos. Práticas de Sucesso: Um Estudo em Projetos no Brasil.

MagnoXavier_UniversidadRosario_Premiação 2014 - WEB-245

 

FINALISTA: Cristiano Rodrigues Barcellos / Universidade de São Paulo – São Paulo/SP 

TCC: O gerenciamento das partes interessadas e o seu impacto no sucesso do projeto, um estudo de caso na indústria.

CristianoBarcellos_USP_Premiação 2014 - WEB-262

 

FINALISTA; Ronielton Rezende Oliveira / Universidade FUMEC .
TCC: Antecedentes do Desempenho do Escritório de Gerenciamento de Projetos.

Ronielton_FUMEC_Premiação 2014 - WEB-274

 

Prêmio PMO Ano:

VENCEDOR PMO DO ANO: Banco Central do Brasil – Bruno Peres de Aguiar / Marcelo Cota

Bruno_BancoCentralBrasil_Premiação 2014 - WEB-185

 

FINALISTA: Stefanini Consultoria – Washington Souza / Braulio de Carvalho

WashingtonBraulio_Stefanini_Premiação 2014 - WEB-205

 

FINALISTA: Banco Itaú-Unibanco – Efigênia Amoroso

EfigeniaAmoroso_Itau_Premiação 2014 - WEB-225

 

Gerenciando Projetos com MS-Project 2013 na Prática

MS-Project 2010 / 2013

EXERCÍCIO PRÁTICO – GERENCIAMENTO DO TEMPO EM PROJETOS

Veja o tutorial em www.youtube.com/mariotrentimPMP

 

  1. Ajustes Iniciais
    1. Projeto deve iniciar em 01/08/2014
    2. Incluir o feriado de 07/09/2014 no Calendário do Projeto
    3. Tarefas Agendadas Automaticamente
    4. Inserir um marco no início do projeto
    5. Inserir um marco ao final do projeto

 

  1. Definir EAP (conforme a figura a seguir)
    1. Criar Subprojeto 1: Veículo Aéreo
      1. Inserir pacotes e salvar
    2. Criar Subprojeto 2: Instalações
      1. Inserir pacotes e salvar
    3. Criar Projeto Master: Sistema da Aeronave
      1. Inserir subprojetos
      2. Inserir pacotes e salvar
    4. Mostrar números da EAP

 EAP

Figura 1 – Estrutura Analítica do Projeto para o exercício

  1. Definir Atividades
    1. Incluir pelo menos uma atividade para cada pacote de trabalho
    2. Incluir uma atividade recorrente para Reuniões de Acompanhamento no pacote de Gerenciamento do Projeto

 

  1. Sequenciar atividades:
    1. Dependências Obrigatórias
    2. Dependências Externas
    3. Dependências Arbitradas

 

  1. Estimar Recursos
    1. Criar Pool de Recursos em um arquivo separado. Salvar como “Somente Leitura”
      1. Importar Pool (Tipo Trabalho)
Nome Grupo Quantidade Taxa
João Eng 50% R$100
Carlos Eng 100% R$120
Flavia Adm 100% R$100
Tec. Eletronica Tec 300% R$70
Advogado Adm 100% R$150
Gerente do Projeto Adm 100% R$100

 

  1. Importar / Compartilhar o Pool de Recursos para o Projeto Sistema da Aeronave e seus subprojetos.

 

  1. Planilha de Recursos
    1. Inserir Planilha de recursos (Tipo Material)
Nome Grupo Quantidade Taxa
Empresa – Veículo Aéreo EMP 1und R$100.000,00
Construtora – Instalações EMP 1und R$500.000,00

 

  1. Inserir um recurso do tipo Custo para consolidar Viagens

 

  1. Estimar durações das tarefas
    1. Analóga
    2. Paramétrica
    3. Bottom-up
    4. Histórico / Benchmarking

 

  1. Atribuir recursos
    1. Utilizar filtros
      1. Atribuir 1 Eng que esteja disponível para trabalhar 8h por dia
      2. Atribuir 1 Adm
  • Atribuir Técnicos
  1. Verificar superalocações (Uso dos Recursos e Gráfico)
  2. Nivelar usando Planejador de Equipe
  3. Nivelar recursos usando “Nivelar Tudo” (Guia Recursos)

 

  1. Obter Cronograma
    1. Refinar atividades, inserindo Detalhes da Tarefa
      1. Descrever detalhes para os pacotes de Treinamento e de Testes
    2. Linkar documentos às tarefas
      1. Linkar figura da EAP
      2. Contratos (.doc) ligados aos subprojetos
    3. Adicionar descrição aos recursos
      1. Descrever as habilidades do Carlos (5 anos de experiência, mestrado em aerodinâmica etc)
      2. Inserir periodo de férias para Flávia (Dezembro/2014)
    4. Mostrar Caminho Crítico
    5. Verificar Diagrama de Rede
    6. Personalizar Gráfico de Gantt
      1. Retirar nomes dos recursos nas tarefas do Gantt
      2. Incluir nomes das tarefas no Gantt
    7. Inserir um novo tipo de tarefa EXTERNA com a cor amarela, utilizar Flag1
      1. Na Planilha, renomear Flag1 para Externa
      2. Marcar os pacotes dos Subprojetos como SIM para Externa
    8. Incluir coluna para mostrar os Custos
    9. Mostrar tarefa de Resumo do Projeto
    10. Salvar o arquivo do Projeto
    11. Definir Linha de Base

 

  1. Monitoramento e Controle
    1. No modo de visualização Tracking Gantt, atualizar o progresso das tarefas
      1. Usando a % completa
      2. Usando datas de início e término real
    2. Mostrar Linha de Progressão
    3. Definir Data de Status (Guia Projeto)
    4. Simular tarefas atrasadas
      1. Verificar Linha de Progressão
      2. Destacar (highlight) tarefas atrasadas
    5. Visualizar Resumo do Projeto (Guia Projeto)
    6. Visualizar Gráfico do Valor Agregado
      1. Explicar VA, VP e CR
    7. Imprimir relatório de Resumo do Projeto
    8. Customizar Relatórios

 

Gerenciando Projetos com MS-Project 2010 | Exercício

Neste post, atendendo a pedidos, estou publicando o roteiro de um exercício realizado no MS-Project 2010. Os videos (tutoriais) estão disponíveis no Youtube ao final deste post.

Na próxima semana, vamos apresentar um outro exercício mais elaborado com funcionalidades avançadas, agora usando a versão atual do Microsoft Project (MS-Project 2013).

 

EXERCÍCIO
Gerenciando Projetos com MS-Project 2010 / 2013

1. Antes de iniciar o projeto, criar o PLANO DE GERENCIAMENTO DO TEMPO (confira os posts Parte 1 e Parte 2). O cronograma final deverá ser incorporado ao plano posteriormente.

2. Ajustes Iniciais
a. Projeto deve iniciar em 01/08/2014
b. Incluir o feriado de 07/09/2014 no Calendário do Projeto
c. Inserir um marco no início do projeto
d. Inserir um marco ao final do projeto

3. A EAP do projeto está desenhada a seguir. Observe que algumas tarefas (verbos) já estão sugeridas para cada pacote de trabalho.

eap - pacotes e tarefas

4. Definir Atividades
a. Inserir EAP e pacotes de trabalho no MS-Project
b. Incluir atividades nos pacotes de trabalho
c. Incluir um novo pacote de trabalho chamado Gerenciamento do Projeto
d. Incluir uma atividade recorrente para Reuniões de Acompanhamento no pacote de Gerenciamento do Projeto

5. Sequenciar atividades. Justifique / Documente.
a. Descrever dependências
i. Obrigatórias
ii. Externas
iii. Arbitradas

6. Estimar recursos
a. Planilha de Recursos (Trabalho) – Disponibilidade
Screen Shot 2014-11-13 at 23.45.43

b. Planilha de recursos (Material)
Screen Shot 2014-11-13 at 23.45.59

c. Inserir um recurso do tipo Custo para consolidar custos de Testes

7. Estimar durações. Justifique / Documente.
a. Descrever ferramentas de estimativa
i. Analóga
ii. Paramétrica
iii. Bottom-up
iv. Histórico / Benchmarking

8. Atribuir recursos. Atenção para as atribuições (esforço, homem-hora)

a. Utilizar filtros
i. Atribuir 1 Eng que esteja disponível para trabalhar 8h por dia
ii. Atribuir 1 Adm
iii. Atribuir Técnicos
b. Verificar superalocações (Uso dos Recursos e Gráfico)
c. Nivelar usando Planejador de Equipe

9. Obter Cronograma
a. Refinar atividades, inserindo Detalhes da Tarefa
i. Descrever detalhes para os pacotes de Ensaios
b. Linkar documentos às tarefas
i. Linkar figura ao pacote CAD
ii. Linkar Contratos (.doc) aos subprojetos pacotes que envolvem fornecedores
c. Adicionar descrição aos recursos
i. Descrever as habilidades do Carlos (5 anos de experiência, mestrado em aerodinâmica etc)
ii. Inserir periodo de férias para Flávia (Agosto/2014)

d. Mostrar Caminho Crítico

e. Verificar Diagrama de Rede. A rede está fechada? Existem tarefas soltas? Corrigir se necessário.

f. Personalizar Gráfico de Gantt
i. Retirar nomes dos recursos nas tarefas do Gantt
ii. Incluir nomes das tarefas no Gantt
iii. Inserir um novo tipo de tarefa EXTERNA com a cor amarela, utilizar Flag1
iv. Na Planilha do Gráfico de Gantt, renomear Flag1 para Externa
v. Marcar os pacotes como fornecedores como SIM para Externa
g. Incluir coluna para mostrar os Custos
h. Mostrar tarefa de Resumo do Projeto
i. Salvar o arquivo do Projeto

TUTORIAIS Youtube: www.youtube.com/mariotrentimPMP

  • Gerenciando Projetos com MS-Project 2010 | Exercício Parte 1/3

  • Gerenciando Projetos com MS-Project 2010 | Exercício Parte 2/3

  • Gerenciando Projetos com MS-Project 2010 | Exercício Parte 3/3

Papel do Gerente de Projetos vs Analista de Negocios

A pergunta que eu mais ouço dos meus alunos é “Professor, o gerente de projetos precisa de conhecimentos técnicos sobre o produto / resultado do projeto?”. Existe muita controvérsia em torno deste assunto, inclusive já foi alvo de outros posts aqui no Blog MundoPM:

 

Existem  pessoas que defendem ser possível gerenciar qualquer tipo de projeto, bastando conhecer as melhores práticas e metodologias.

Na minha opinião, o gerente de projetos, como todo gerente, deve conhecer os drivers do negócios, bem como os principais aspectos técnicos e gerenciais relacionados ao seu projeto. Obviamente, o GP não precisa dominar todos detalhes técnicos do projeto, mas ele precisa ser capaz de fazer as perguntas certas.

Imagine que você é um gerente de projetos de TI, acostumado com ciclos de vida de desenvolvimento de software. Já pensou gerenciar um projeto de construção civil? Supondo que você não conhece nada de construção, terá dificuldade logo no início do projeto. Elaborar o plano de gerenciamento do projeto, coletar requisitos e definir o escopo serão tarefas muito difíceis. Além disso, se você não souber ao menos desenhar uma EAP (Estrutura Analítica do Projeto) macro, qual será sua credibilidade perante a equipe e demais stakeholders?

it

Figura 1 – Ciclo de vida de um projeto de software (exemplo)

preview_html_142dbeab

Figura 2 – Estrutura Analítica do Projeto para construção civil (Fonte: Plano de Projeto – Logística Integrada em Obras)

 

Neste post, queremos chamar a atenção para dois outros papeis extremamente importantes, além do gerente do projeto:

  • Líder Técnico / Engenheiro Chefe ou de Sistemas
  • Analista de Negócios

O gerente do projeto é responsável por planejar, orientar e controlar a execução do projeto, coordenando pessoas e recursos, gerenciando a programação de tarefas, orçamento e demais áreas do projeto.

 

O Analista de Negócios desempenha o papel de elo de ligação entre as partes interessadas e os objetivos organizacionais e do projeto, sendo responsável por detalhar o problema ou oportunidade, bem como a justificativa do projeto.

 

O Líder ou Responsável Técnico, podendo ter outras designação, é um profissional sênior de grande conhecimento, experiência e capacitação técnica no produto do projeto. Ele é o responsável pelos aspectos técnicos da solução.

 

Análise de Negócios e o Analista de Negócios vem ganhando importância no gerenciamento de projetos. O Project Management Institute recentemente lançou a certificação PMI-PBA (Professional in Business Analysis). Inclusive, no PMI Global Congress 2014, havia um track específico de Business Analisys e a hastag #BAatPMI.

Para aqueles que desejarem saber mais, vale a pena conferir os eventos online que continuam ocorrendo:

 

No próximo post, falaremos mais sobre Business Analysis e suas certificações. Não percam!

Integração traz resultados! Por que Engenharia de Sistemas e Gestão de Programas devem estar alinhados?

 

Integration_picConforme prometido, escrevo este post com o objetivo de mostrar uma síntese das apresentações e material utilizado em minhas exposições durante o PMI Global Congress 2014, realizado em Outubro, na cidade de Phoenix, Arizona. Neste post vou resumir os principais tópicos da primeira apresentação que aconteceu na tarde de domingo, primeiro dia do evento, e cujo título foi: “Integration means results: why Systems Engineering and Program Management must align”. Eu dividi o palco com o Dr. Eric Rebentisch, pesquisador responsável pelo Consortium for Engineering Program Excellence (CEPE) no Massachusetts Institute of Technology (MIT), onde o estudo está sendo desenvolvido.

Nesta primeira apresentação discutimos os principais resultados de um programa de pesquisa cujo objetivo é melhor compreender o relacionamento entre as disciplinas de Gerenciamento de Programas (Program Management – PM) e Engenharia de Sistemas (Systems Engineering – SE), duas disciplinas de muita importância para projetos complexos e de grande porte, e que estão sendo adotadas em conjunto por grandes corporações de todo o mundo em setores como defesa, aeroespacial, construção naval, construção e infraestrutura, tecnologia, energia, exploração, etc.Motivation_pic

Estamos em busca de responder questões como: o que significa Integration?; Como aprimorar o desempenho de programas por meio da melhoria da integração entre gestão de programas e engenharia de sistemas? Quais são as causas dos problemas que afetam negativamente a integração entre PM e SE?

Trata-se de um estudo que já está em sua quarta fase e que começou em 2012, com uma survey conduzida em parceria com o PMI e INCOSE, onde participaram mais de 600 profissionais somando-se as duas áreas de foco. Clique aqui para ter uma cópia do relatório parcial do estudo.

Identificamos, a partir da análise dos resultados da survey conduzida em 2012, e a fase de estudos de caso com empresas de diferentes setores e porte, algumas das principais fontes de problemas que afetam a integração entre PM e SE, por exemplo:

  • tension_PM_SE_picAusência de um planejamento integrado entre as duas disciplinas e competências. Planejamento que integre as duas áreas e profissionais na construção de uma visão única sobre o programa;
  • Dificuldade em desenvolver uma visão compartilhada dos objetivos do programa para os envolvidos;
  • Ausência de clareza na definição da autoridade e processo de decisão que esteja claro para cada profissional atuando nessas áreas;
  • Conflito entre práticas das duas disciplinas ou sobreposição de práticas que não estão bem definidas no processo de desenvolvimento do programa e produto e gestão do programa.
  • Indivíduos ou grupos de profissionais focados em metas que atendam apenas sua área de escopo, atuação ou função, sem uma visão holística de processo;
  • Deficiência na definição dos papéis e responsabilidades de cada área e profissional envolvido;
  • Dificuldade em trabalhar de forma colaborativa visando um resultado superior com impacto relevante para o programa;
  • Expectativas pouco claras, mal definidas pelo patrocinador do programa, dentre outras.

Em contrapartida, conversando com profissionais de empresas que não tem problemas com a integração entre essas duas áreas, identificamos alguns aspectos chave e quais práticas aparentemente são comuns para essas organizações e que, segundo os entrevistados, contribuíram para a melhor integração entre PM e SE. Por exemplo:

  • Formalizar o entendimento da importância da integração entre essas duas disciplinas e como esta integração pode ser observada e mensurada na sua organização;
  • Utilizar padrões de práticas reconhecidas de ambas as disciplinas (Program Management e Systems Engineering).
  • Fornecer treinamento em ambas as áreas de conhecimento, pelo menos, no que tange os conceitos básicos e pontos em que há sobreposição de processos e práticas. O ideal é que este treinamento esteja disponível para todos os envolvidos no programa, com diferentes níveis de detalhamento nos conceitos e práticas;
  • Definir de forma clara os papéis e responsabilidades dos profissionais atuando em cada área; identificar as áreas onde as responsabilidades serão compartilhadas, onde estão os pontos de maior tensão nos quais a colaboração terá papel fundamental na resolução de problemas;
  • Desenvolver modelos integrados para avaliação do programa que inclua aspectos da engenharia de sistemas e da gestão do programa como um todo;
  • Compartilhar responsabilidades entre o chefe da engenharia de sistemas e o gestor do programa em áreas críticas, previamente identificadas no planejamento integrado entre as partes, tais como: riscos, qualidade, aquisições, desenvolvimento de fornecedores e parceiros de desenvolvimento.

Ainda relacionado com este tema, no terceiro dia do evento tivemos uma mesa redonda com especialistas convidados para discutir casos reais e práticas adotadas em suas organizações. O título da mesa redonda foi: “The Inside View on Effective Engineering Program Management”.

Em resumo, alguns dos principais aspectos mencionados pelos especialistas foram:

  • Conhecimento, Profissionais com competências específicas para cada posição: ajuda bastante se o gestor do programa tiver uma formação em engenharia de sistemas e conhecer profundamente a tecnologia ou aspectos do desenvolvimento do produto. Este poderá transitar melhor entre as áreas identificando pontos comuns e possíveis problemas. Mas é inevitável que este profissional tenha diferentes competências para ser capaz de assumir a gestão do programa como um todo;
  • Manter os membros do time trabalhando juntos por mais tempo: isso é crítico, e foi mencionado que o gestor do programa e o responsável pela engenharia precisam ter “horas de experiência” trabalhando juntos. A mesma dica aplica-se para o time, quanto mais tempo passarem trabalhando e colaborando melhor será o desempenho do grupo e a tendência é que a integração também melhore;
  • Cultura organizacional: é importante ter um ambiente que estimule a colaboração e o trabalho conjunto, e a integração entre as diversas áreas de uma organização. Ter times multidisciplinares também tem papel fundamental na resolução de problemas e mudanças no programa;
  • Processos, práticas e ferramentas: é importante ter um alinhamento entre processos, práticas e ferramentas adotadas por ambas as disciplinas e este alinhamento deve ser ilustrado de forma clara para todos os envolvidos;
  • Proximidade entre os profissionais (co-localização): a proximidade física é um fator relevante para a integração, em especial em programas complexos com grande fluxo de informação entre os envolvidos. A proximidade facilita as interações e comunicação entre os profissionais, e proporciona oportunidade para interações frequentes;
  • Pontos de controle e avaliação: mais especificamente relacionado ao processo de desenvolvimento, é importante definir pontos de controle e avaliação do progresso e desempenho do programa onde todos os participantes podem estar juntos, avaliando o que foi realizado, com a oportunidade de discutir como solucionar problemas e melhorar o processo e os resultados.

Bem, esses foram alguns dos pontos destacados pelos participantes desse painel que puderam responder perguntas dos ouvintes, contribuindo para a troca de experiências e conhecimentos nesta temática.

Espero que a leitura tenha sido produtiva!

Até o próximo post! Grande Abraço,

Edivandro

A Lei de Ashby, a teoria da agência e a gestão de projetos

Muito vem se discutindo na área de gestão de projetos sobre como tomar decisões mais acertadas e claras. A grande questão é como preparar gestores que sejam capazes de absorver grande quantidade de variáveis e interpreta-la a fim de gerar melhor produtividade e resultado aos projetos. O objetivo deste post é de levar ao grande público questões ainda pouco exploradas pelas ciências sociais aplicadas em seu impacto na gestão de projetos.

 

Complexidade é um tema que vem sendo cada vez mais abordado em suas aplicações na gestão de projetos. Dinâmicas de sistemas, sistemas complexos adaptativos, teoria do caos… o que tem em comum nesses temas é a grande quantidade de variáveis e a possível combinação dentre eles, o que torna a previsibilidade quase uma utopia.

 

Entender essa dinâmica pode levar muito tempo, e consumiria uma grande quantidade de esforço dos gestores de projetos, o que poderia a não levar a ganhos imediatos: fato esse que poderia gerar desinteresse imediato. Para buscar um inicio de entendimento para essa complexa teia de conhecimento, a lei que rege o entendimento dos sistemas de controle é o ponto de partida. A lei da variedade requerida, ou lei de Ashby, estabelece que um sistema de controle deve ter quantidade de variedade possíveis de adaptabilidade tal qual o sistema que ele quer controlar.

 

A redução de variedade para absorção de variedade é apontada como possível solução para lidar com a complexidade intrínseca dos sistemas de controle gerenciais, tendendo assim a facilitar a tomada de decisão de seus gestores.

 

Na gestão de projetos isso pode se manifestar através da aplicação de uma metodologia em gestão de projetos para uma organização. Embora um tamanho único provavelmente não sirva para ninguém na organização de forma completa, é viável a aplicação de procedimentos de forma a viabilizar o trabalho colaborativo. Isso é relevante quando observado o problema do principal–agente, dilema da agência ou também conhecida como teoria da agencia.

 

A teoria da agencia trata das dificuldades que podem surgir em condições de informação assimétrica e incompleta, quando um principal (patrocinador) contrata um agente (gestor de projetos). O problema de potencial conflito de interesses e risco moral, na medida em que o principal está, presumivelmente, contratando o agente para prosseguir os interesses do principal. Em gestão de projetos é comum que o gestor de projetos não esteja alinhado com os interesses do patrocinador, seja por falta de contrato psicológico, seja por não proximidade física.

 

Esse desalinhamento entre os interesses deu origem ao que é conhecido como gestão de partes interessadas. Neste caso a gestão de projetos, através da criação de um referencial de regras (plano de projeto) atua como agente regulador de diminuição de variáveis, ajustando o interesse das partes, auxiliando em sua gestão, colocando em prática a lei de Ashby.

 

A questão de como desenvolver uma metodologia de gestão de projetos que seja aceita e compreendida pelas partes é o grande desafio do gestor de projetos. Esse estabelecimento depende do contexto de negócio, das pessoas envolvidas no processo e das ferramentas que ele escolheu para minimizar a quantidade de variáveis a serem levadas em consideração na sua tomada de decisão, e consequente utilização dessas ferramentas como fonte de informação e base para comunicação do processo de gestão. Esse desafio deve levar em consideração o mapeamento das competências deste gestor levando em consideração as três variáveis supra citadas.

 

Face ao exposto, pode se perceber que a lei de Ashby é recorrente em um mundo onde a complexidade e a interação entre sistemas é cada vez maior, gerando assim uma quantidade de variáveis a serem levadas em consideração tendendo ao infinito. Para tratar dessa complexidade, a redução de variáveis é fato critico para a tomada de decisão do gestor de projetos. O desenvolvimento de uma metodologia pode ser o cominho para criação de uma estrutura clara de controle, que favorece em primeiro lugar o patrocinador da organização, tendo em vista que a teoria da agência é um fato consumado em estruturas organizacionais. Esse desenvolvimento deve envolver, por parte do gestor de projetos, o desenvolvimento de competências contextuais, comportamentais e técnicas em gestão de projetos com o fito de atingir os resultados para a organização e para si mesmo.