O que é um Project Office?

O Project Office é uma estrutura organizacional de apoio:

• aos líderes dos projetos, para facilitar a obtenção dos objetivos do projeto e
• às instâncias superiores da empresa, com um papel de assistência à tomada de decisões.

Em suas funções de suporte ao chefe de projeto, o PMO (Project Management Office) se encarrega de uma ou mais missões entre as mencionadas a seguir:

• assumir uma parte das tarefas administrativas dos projetos
• desenvolver e manter as normas e os métodos de gerenciamento de projetos
• propor serviços de treinamento ao gerenciamento dos projetos
• propor consultorias e coaching para os chefes de projetos

O PPM (Portfolio Project Manager) também pode dar suporte às direções através da gestão do portfólio de projetos. Ele pode ser comparado a uma "torre de controle" para o conjunto dos projetos de uma determinada diretoria ou mesmo de toda empresa, e pode estar vinculado hierarquicamente a uma alta unidade corporativa da empresa.

Para procurar garantir resultados adequados à gestão do portfólio de projetos, uma linguagem comum se revela fundamental permitindo, assim, comparar os projetos entre eles e consolidar os elementos de controle (orçamento, planejamento, etc). Uma linguagem comum também permite produzir coerência no conjunto dos procedimentos de gestão e permite fazer arbitragem na alocação dos recursos dos diferentes projetos.

Fonte: Trecho extraído da revista MundoPM, edição de junho/julho de 2010, págs. 45 e 46.

Como fazer as pessoas renderem mais?

É preciso engajá-las, treiná-las todos os dias e deixar claras as suas expectativas. Se um problema é recorrente é porque o funcionário não sabe quais passos deve seguir para evitá-lo.

O que as pessoas esperam de um chefe?

Quem tem baixo desempenho quer um chefe que não sabe o que faz, que não acompanha os projetos e ignora os problemas de desempenho. Já os profissionais de alto desempenho preferem chefes fortes e engajados, que sabem exatamente o que querem e o que estão fazendo.

O líder já nasce pronto?

Poucos gestores têm carisma e entusiasmo para inspirar e motivas as pessoas. Você não vai aprender a ser carismático, mas pode aprender a se comunicar de um jeito simples e eficaz. Com isso, seus subordinados saberão exatamente o que devem fazer e como contribuir para a companhia. A dica é praticar, praticar e praticar, até as técnicas de liderança se tornarem conhecimento e depois passarem a ser um hábito.

Qual o maior desafio dos líderes jovens?

Eles assumem o cargo sem apoio e orientação e têm dificuldade de estabelecer credibilidade e obter respeito. Assim, eles se tornam autoritários e passam a ser mais dependentes de outras pessoas. É o primeiro passo para a frustração e o fracasso.

Qual a diferença entre um líder e um gerente?

O objetivo do líder é inspirar, apoiar e dar uma orientação geral sobre o negócio. Já o gerente é o responsável por orientar, dirigir e executar os projetos. Existem poucas pessoas em cargos de liderança que conseguem reunir as características de líder e gerente.

Define How Your Team Will Work

Most team leaders know to help their team define goals, but the conversation shouldn’t stop there. You also need to agree on the mechanics of how the team will get the work done. Here are four things that need to be clear on every team: 

• Roles and responsibilities. Every member needs to know their tasks and how their work will contribute to the overall goals.
• Work processes. You don’t need a notebook full of procedures, but agree on how to carry out the basics — such as decision-making or communicating.
• Rules of engagement. Establish a constructive team culture. Discuss the shared values, norms, and beliefs that will shape the daily give-and-take between team members.
• Performance metrics. How will you measure progress? Define the measures for meeting the goals, and the consequences for not meeting them.

Desenvolvedores, designers e gerentes de projeto

Por Denis Ferrari

Uma imagem vale mais do que mil palavras, segundo a sabedoria popular. A imagem “The War Between Developers, Designers and Project Managers” resume com maestria boa parte dos sentimentos que encontramos no mercado de desenvolvimento de software atualmente.

Apesar de entender o propósito da imagem (e rir também), como desenvolvedor, tenho uma impressão diferente do que foi apresentado no primeiro bloco de imagens. Acredito que os dois últimos lugares em que trabalhei me ajudaram a entender bem o papel do desenvolvedor, do designer e do gerente de projetos, papel que desempenhei por algum tempo.

Sobre designers

Aprendi muito sobre a atividade dos designers enquanto trabalhava na Vixtime, onde entregávamos basicamente projetos web nos quais software era o “meio” e não o fim. Nesse tipo de projeto, ter um software funcional e rápido é obrigação, mas ter um layout bonito é um grande diferencial. Muitos clientes batiam à nossa porta pedindo um projeto tão bonito quanto os do no nosso portfólio. Pessoas dão importância à estética de um projeto. Quanto mais cedo você entender isso, mais cedo vai poder tirar proveito dessa característica.

Além da parte estética, os designers avaliam toda a experiência que o usuário terá interagindo com o projeto, o que resulta, na maioria das vezes, em um projeto muito mais fácil e prático de ser utilizado. Acha que estou falando bobagem? Se você for na Apple Store, perceberá que vários aplicativos de uma determinada categoria têm basicamente as mesmas funcionalidades, porém, os aplicativos que foram projetados especificamente para usuários de iPhone têm maior aceitação, e por consequência um maior número de vendas.

Sobre gerentes de projeto

Acho que essa imagem explica bem o porquê de vários programadores que conheço almejarem o cargo de gerente de projetos.

A função (não o cargo) de gerente de projetos é bem complexa. Você tem que estar ligado em vários aspectos do projeto simultaneamente, se comunicar o tempo todo e deixar todos os envolvidos cientes do cenário atual, além de muitas vezes ter que fazer tudo isso com vários projetos correndo ao mesmo tempo.

Nas vezes em que desempenhei esse papel, procurei fazer o que acredito ser a missão de todo bom gerente: deixei a equipe trabalhar e fazer o seu melhor onerando o mínimo possível sua rotina de trabalho com burocracias. Tive sorte de trabalhar com equipes competentes e responsáveis.

Tive também a sorte de ter bons gerentes de projeto, salvo uma única exceção. Depois que você sente na pele a responsabilidade de um grande orçamento, você aprende a dar valor a esse tipo de profissional. Os melhores gerentes de projeto são menos gerentes e mais líderes, ainda assim, alguns modelos de liderança são levemente desagradáveis.

Sobre desenvolvedores

Como desenvolvedor, não me vejo como um cientista, mas entendo que a imagem queira representar o ego de muitos desenvolvedores que, por serem mais experientes, se sentem dessa forma. Conhece algum desenvolvedor com ego inflado? Então.

Desenvolvedores tocam o projeto, o fazem funcionar, mas não são capazes (na maioria dos casos) de cuidar de todos os seus aspectos, como design, usabilidade e gerência. O desenvolvedor é uma parte importante (mas ainda assim apenas uma parte) do tripé que sustenta o projeto. Adoro ser desenvolvedor, mas entendo que sozinho sou apenas parte do que um projeto precisa para ter sucesso.

Resumindo

Existem muitas falhas de comunicação na relação entre desenvolvedores, designers e gerentes de projeto. Muitas vezes, uma função é estereotipada por causa de um mal profissional com o qual esbarramos na nossa carreira. Enfim, acredito que se manter em perspectiva e procurar sempre visualizar o cenário como um todo é uma boa forma de realmente entender o meio em que estamos inseridos e as pessoas que o formam.

Denis Ferrari um profissional com foco em qualidade e melhoria das técnicas e metodologias de desenvolvimento de software. Especialista na plataforma .NET, atua como Arquiteto de Software na Mindworks. Escreve artigos para os principais portais de desenvolvimento e também para o blog Heróis da TI. Capixaba, atua na comunidade local através de palestras gratuitas e participação ativa nos principais grupos sobre .net e metodologias ágeis.

Brief History of Project Management

Imagine that an important customer in your firm commissions you to complete a sophisticated worldwide market study that will form the basis of a global expansion strategy. Or that you are responsible for the development of the product which will determine your firm’s ability to go public. Or that you are in charge of handling the merger of your firm with another. Further imagine that in these situations you receive a strict budget and a precise schedule. You are, as such, involved in a project—and, moreover, you are involved in managing a project. Deliverables must be completed according to a schedule, which is usually aggressive, and within a budget, which is usually fixed.

Because project management focuses on specific results (deliverables), time and (schedule), resources (money, people, etc.), a series of techniques and processes has evolved to help people efficiently manage these undertakings. This module will introduce these to you.

The Origins Of Project Management
“Work” was first scientifically studied by Frederick Taylor (1856-1915), who also was the first to consider process design. But not until the early 1950s were many project management techniques assembled into a single, coherent system: the focus of that enormously complex effort was the U.S.

Defense Department’s development of the Polaris missile. The techniques, which included Henry Gantt’s chart, which he created to manage Army logistics, were essential to managing the intricacies of how work among an array of specialists would be handed off, and how the schedule itself would be managed. At the center of this effort was literally a project “war room,” which prominently displayed huge Program Evaluation Review Techniques (PERT) charts.

Following quickly in the military’s footsteps were the automotive and movie industries, and private and public engineering organizations. All shared the need for creating unique outcomes, and they found that project management techniques helped cross-functional teams define, manage, and execute the work needed to accomplish these ends. Along with such techniques as histograms and network diagrams, early practitioners of project management also employed the concept of a project life cycle and began to incorporate that thinking when generating more complex Work Breakdown Structures (WBSs). A WBS comprehensively identifies the individual tasks required to achieve an objective.

More recently, new project management techniques (e.g., for creating cross-functional schedules, managing shared resources, and aligning project portfolios), the widespread use of personal computers, and the growing sophistication and availability of project management software tools have all increased the effectiveness of a methodology for addressing a variety of project problems.

The Emerging Importance of Projects
But it is not simply the improvement of project management effectiveness that we are examining; other forces combined to cause the use of these techniques to explode. Powerful competitive pressures to manage and reduce product cycle time are increasing, as is the globalization of many markets and the recognition of projects as a key link between the strategic goals of the organization and the tactical work being performed by discrete functions.

As a result, industries as diverse as computer manufacturing, consulting services, pharmaceuticals, photography, and natural resource management have aggressively implemented project management. These industries, and a myriad of others, are using project management as a way to create the future, by better understanding both customer requirements and solutions to meet them. Moreover, project management has a potent effect on a firm’s bottom line.

An international study found that “when companies increased their predevelopment emphasis, they increased the predictability of successful new-product commercialization by a 2-to-1 ratio.” When predevelopment activities, primarily project definition and planning, increased, so did the likelihood of product success. Some key factors separating success from failure were:
• “Winners spent more than twice as many resources on predevelopment activities as did losers.
• Seventy-one percent of new-product development was delayed due to poor definition and understanding of customer requirements.
• Changing product requirements induced more delays in product development than any other cause.” (Boznak, 1994)

Project management also affects the bottom-line because it helps cross-functional teams to work smarter. It enables teams to better draw upon the individual strengths of members by providing an efficient infrastructure for defining, planning, and managing project work, regardless of the structure of the firm’s organization.

It is particularly useful in specialized functional environments or highly matrixed environments, since it channels specialization into clearly defined project cooperation and contribution activities and clarifies ambiguous roles and responsibilities. Thus, as one author observed, “Team members derive value from the summary data for project planning, estimation of tasks, and identifying improvement opportunities, such as activities that ought to have more (or less) time devoted to them.

The data provides a quantitative understanding of the group’s development process as well as a way to monitor of the process over time. It has been enlightening to many team members to compare where they think they spend their time with where they actually spend their time” (Wiegers, 1994).

Similarly, “Successful firms have mastered the art of melding the power of human will and organization. But the key to their vitality is their world class capabilities in selecting, guiding, and completing development projects, which are the building blocks of renewal and change. The companies that can repeat this process again and again have discovered the manufacturer’s perpetual motion machine” (Bowen, Clark, Holloway and Wheelwright, 1994, p. 14).

As yet a further example of this impact, Integrated Project Systems conducted two studies (unpublished) in which one computer manufacturer gained a 500% return on investment in project management by creating a project plan template for repetitive projects, and another had an estimated 900% return on investment through an early cancellation of a troubled project. ROI on implementing project management appears to be quite significant.

Fonte: Harvard Business School 9-697-034, Rev. October 6, 1997

Colaboração de Fernanda Schwarzstein

Para descontrair...

A mais pura verdade...

Scrum Master em menos de 10 minutos

Muito prático e objetivo. Narrado em inglês!

10 erros na implantação do Scrum que voce não quer cometer

Por Eli Rodrigues,

Muitas empresas de software tem buscado a “solução mágica” no Scrum, mas não estão obtendo o resultado esperado. A maioria delas, após alguns meses, desiste do framework e volta ao ad-hoc, culpando-o pelo fracasso. Mas será que essas empresas estão implantando corretamente?

Pelo que tenho visto, a maioria tem feito “adaptações” no framework que tiram algumas de suas características essenciais. Por exemplo, o intenso ciclo de comunicação garante alinhamento de expectativas; a constante revisão de escopo garante coesão no projeto; as entregas intermediárias buscam atendimento da necessidade do cliente e correção de falhas antes do final do projeto; o conceito de timebox força a equipe a ter o que entregar, evitando o prolongamento de atrasos. Ora, esses benefícios são provenientes dos princípios embutidos no Scrum e adaptar o processo pode trazer resultados desastrosos.

Mas quais são os erros mais frequentes? Fiz um levantamento de erros comuns e que levam a implantação do Scrum ao fracasso:

1) - Vestir a capa de scrum, mas trabalhar cascata

Sprints são timeboxes, ou seja, um tempo fechado em que se realizam entregas parciais do projeto. As entregas são priorizadas para que, ao final do tempo, exista uma ”saída”, “alguma” entrega.

Montar sprints como etapas ou fases de um projeto é um erro. Dessa forma perdem-se os benefícios do ciclo de melhoria contínua (que muito lembra o PDCA), mais conhecido como iterativo-incremental, que grossomodo significa entregar parcialmente e agregar valor ao produto a cada ciclo, através da melhoria contínua. Portanto, é importante que as entregas sejam parciais e evolutivas.

2) - Impor prazo de “cima para baixo”

A definição de “prazos arbitrários” é uma prática condenada também pelo PMI, deve-se envolver os executores das atividades na fase de Planejamento. O Scrum não precisa de nada disso, ele trabalha com sprints e invés de um prazo fechado. Precisam-se de entregas priorizadas para que a equipe “decida” o que vai ser entregue, caso no prazo não seja possível terminar tudo.

Existe muita polêmica em relação a essa questão, pois as pessoas se sentem desconfortáveis em afirmar que a equipe “poderá não entregar tudo”, mas no mundo real muitas equipes não realizam as entregam na data combinada e atrasam os projetos. O Scrum não quer dizer que a equipe vai fazer “corpo-mole” e deixar de entregar as coisas, pois existe um monitoramento diário das atividades e as entregas são parciais. Desse modo, não haverá aquela pressão do último dia, mas uma pressão a cada sprint, reduzindo o risco de um atraso maior. Além do mais, a equipe fica ciente de que deve fazer primeiro o que for prioridade e que SE for preciso, entreguem parcialmente, mas jamais deixem de entregar no prazo.

3) - Realocar membros da equipe para outros projetos “mais prioritários”

A mudança de prioridade entre projetos não combina muito bem o com o agile, pois ele tem como premissa o trabalho integrado, colaborativo e priorizado. Toda a motivação da equipe no Scrum (segundo minha percepção) vem do agrupamento, do cumprimento de metas e da cobrança mútua, parâmetros estimulados pelo Scrum de um modo geral. Além disso, lições aprendidas, sincronia e alto desempenho serão perdidos com a troca de “componentes” (de pessoas).

4) - Não fazer reunião diária

É na reunião diária que se faz a gestão da equipe, do desenvolvimento das entregas, da qualidade e dos problemas. Não cumprir essa prática rompe com os ciclos de comunicação, acompanhamento e põe em risco a entrega do Sprint. Além disso, o relato de desempenho diário faz com que a equipe se cobre mutuamente impulsionando a produtividade.

5) - Não endereçar e resolver os impedimentos

No Scrum, as pessoas são incentivadas a comentar o trabalho que estão fazendo diariamente (como descrito acima) e também qualquer impedimento que esteja causando impacto em suas atividades. Se você não resolver os impedimentos com muita seriedade, elas simplesmente vão parar de reportar, não cumprirão os prazos e eventualmente até boicotarão o processo. Neste caso, a frase mais comuns nos corredores é: “Eu já falei, mas ninguém faz nada!”.

6) - Fazer a reunião diária sem o quadro de acompanhamento

Sem o quadro de acompanhamento fica impossível controlar o andamento do trabalho. Todo tipo de Controle precisa de uma linha de base de comparação, no caso do Scrum essa linha de base é o quadro de acompanhamento.

7) - Não gerar o gráfico de burndown

O gráfico de burndown é uma das ferramentas mais poderosas de comunicação do Scrum. Permite que clientes, gestores e equipe tenham uma visão real e atualizada do projeto todo. Ele pode ser feito tanto para os Sprints quanto para os itens do Product Backlog e ajuda a prever a data final do projeto. Lembre-se, sem linha de base não existe controle, sem controle não existe sucesso.

8) - Criar sprints estanques

Todo sprint deve ter um objetivo, mas não entregas fixas e invidivisíveis, pois há perda de agilidade. Quando uma entrega está travada (com dificuldade para ser implementada),  a equipe pode decidir passar para a próxima entrega, enquanto os impedimentos são resolvidos, ou montar uma força-tarefa para resolver o impedimento . Isso ajuda a chegar no prazo final com alguma entrega pronta, apesar dos percalços. Sem flexibilidade, a chance de atrasos é muito maior.

9) - Atrasar o prazo final dos sprints

Scrum é timebox,  é ”quanto consigo fazer até o final do sprint”. Isso força a equipe a pensar sempre em entregas funcionais e aceitas pelo cliente, a buscar alternativas, a se superar. Mudar essa perspectiva para “quando consigo entregar um grupo de funcionalidades” pode levar a equipe a atrasos. A pressão deve estar totalmente voltada para a entrega.

10) - Ter um Scrum Master sem autoridade (grupos matriciais)

O Scrum Master precisa de autoridade suficiente para planejar, organizar, comandar, coordenar e controlar as atividades de sua equipe. Se uma autoridade externa influenciar na alocação, impuser prioridades ou simplesmente retirá-los da equipe fica muito difícil o SM conseguir formar uma equipe de alto desempenho, como é esperado. Mas quando a equipe+SM não tem autoridade para determinar as atividades e prioridades dentro do sprint, o resultado é totalmente fora do esperado.

A maior dificuldade para as organizações tem sido mudar o dilema: é melhor ter um prazo ou entregar um produto funcional ao final de um período? É melhor ter um escopo congelado ou entregar um produto que corresponde às necessidades do cliente? É melhor ter atas de reunião e relatórios ou fazer uma comunicação simples e entregar o produto no final do projeto?

Esses princípios têm dado bons resultados em vários lugares ao redor do mundo, analise se sua empresa está realmente seguindo os princípios certos, o melhor indicador são os resultados (entregas e clientes satisfeitos), a metodologia pouco importa.

Eli Rodrigues tem a carreira  dedicada a projetos. É membro ativo do PMI, construindo e compartilhando  conhecimento através de cursos, palestras, artigos e da execução de projetos.

O que torna os gerentes de projeto irritantes?

Por Luiz Paiva,

Como gerentes de projeto, sempre estamos tentando fazer o melhor para o projeto. Ou não? Será que a visão de outros stakeholders não pode ser diferente, e estamos na realidade atrapalhando o trabalho dos demais? Obviamente isto parece um exagero, mas encontrei um artigo no site About.com, que fala sobre o que os desenvolvedores web odeiam nos gerentes de projeto.

O que torna os gerentes de projeto irritantes?

Quando assumem que podem fazer o trabalho da equipe

Gerentes de projeto não devem se meter a fazer o trabalho dos outros, mesmo que já tenham trabalhado nesta área antes. Trata-se de uma questão de foco, respeito e ética. Cabe ao gerente definir escopo, planejar prazos e deliverables e controlar custos, com o apoio da equipe. Também não há nada de errado em discutir diferentes técnicas e metodologias para chegar ao resultado.

O problema está quando o gerente começa a pisar na linha da arrogância e falta de respeito profissional, acreditando que pode fazer o trabalho do outro profissional melhor do que ele. Se o profissional não desempenha, há que substituí-lo, e não fazer o trabalho por ele.

Quando definem prazos ridículos

Definir uma meta de prazo insana não quer dizer que acontecerá. Este tipo de situação torna-se motivo de piada pela equipe, e o gerente perde credibilidade. No projeto, existem pressões naturais para redução de prazo, e o gerente precisa administrá-las para manter a bom senso nas estimativas, e não ceder cegamente ao que o patrocinador ou o cliente desejam.

Quando formalizam opiniões informais

Esta é ótima. Muitas vezes, especialmente em fases iniciais do projeto, o gerente quer obter algumas estimativas macro para seu planejamento. Ele insiste com a equipe que lhe passe alguns números de referência… e depois os formaliza como uma avaliação firme. Este é um “golpe baixo” que criará uma energia negativa da equipe em relação ao gerente de projeto. Pior ainda é quando, em uma reunião, ele pressiona para que se digam números em frente aos outros stakeholders, com o pretexto de que é “para ter uma idéia”. Especialmente quando quem está na reunião é o cliente, está criado o cenário para dificuldades de comunicação no projeto.

Quando estão mais preocupados com relatórios do que com resultados

Reportar atividades é fundamental nos projetos… mas bom senso também. O gerente de projeto deve saber dosar a necessidade de relatórios de status para que não se sobreponham às atividades em si. Mais ainda, deve ter o discernimento para compreender situações nas quais os relatórios devem ser simplesmente ignorados, para atender a necessidades críticas do projeto.

Quando não conhecem os detalhes do projeto

Os gerentes tem uma expectativa de que cada profissional que participa do projeto conheça muito bem sua área de atuação. No entanto, o mesmo é esperado da equipe… que o gerente saiba se comunicar adequadamente sobre o projeto e que tenha as informações chave que a equipe precisa para desempenhar bem suas atividades.

Luiz Paiva é Gerente de Projetos e mantenedor do Site www.ogerente.com

Cursos Preparatórios para Certificação CAPM®

O PMI São Paulo oferece o Curso Preparatório para o Exame de Certificação CAPM® - Certified Associate in Project Management. Este curso é destinado aos candidatos que já possuem os pré-requisitos de elegibilidade para prestar os exames e já têm um estudo prévio baseado, principalmente, no PMBOK® Guide Fourth Edition. Os pré-requisitos estão disponíveis no site do PMI® (www.pmi.org).

Para mais informações, visite a página do PMI São Paulo: http://www.pmisp.org.br/evento/programe-se-curso-preparat%C3%B3rio-para-certifica%C3%A7%C3%A3o-capm-2012

Seminário - Gestão de Projetos baseada em Competências - Modelo IPMA

Seminário Gestão de Projeto baseada em Competências 02/março/2012 Horário: 9:00h as 18:00h A Revista MundoPM e a IPMA-Brasil convidam para o evento "Gestão de Projeto baseada em Competências". Um evento que tem como tema central o Modelo de referencia IPMA Competence Baseline (ICB) para gestão de projetos. Modelo IPMA Competence Baseline (ICB): O IPMA Competence Baseline (ICB) é o referencial de competências em gestão de projetos utilizado por todas as organizações-membro. O olho de competências, conforme Figura abaixo, representa visão e clareza na integração dos três domínios de competência vistos pelos olhos dos gerentes de projetos: 20 elementos de competências técnicas e relacionadas com as técnicas utilizadas pelos profissionais de projetos; 15 elementos de competências comportamentais referentes aos relacionamentos entre indivíduos e grupos atuando na gestão de projetos, programas e portfólios; e 11 elementos de competências contextuais relacionados com a interação do projeto com o contexto da organização permanente e do ambiente em que está inserido. Principais tópicos Abordados: • Gestão de Projetos baseado no Modelo ICB • Casos de Sucesso usando IPMA. • Aplicando o ICB nas Organizações. • Os diferenciais do modelo IPMA. • As certificações do modelo IPMA.  ABERTURA DO EVENTO:  Paulo Roberto Costa - Diretor de Abastecimento da Petrobras Vencedor do Projeto do Ano 2011 pelo projeto da Refinaria do Nordeste (Abreu Lima), maior empreendimento de capital da América Latina. Tema de Abertura: A importancia da gestão de projetos para o desenvolvimento corporativo e de uma nação. Sobre a IPMA-Brasil: IPMABR, NCB - Referencial Brasileiro de Competências versão 2.0, Janeiro 2012, www.ipmabrasil.org Data/Local: 02 março 2012 / Rio de Janeiro Reservas ou dúvidas: ligue 41.3029-9397 ou 11.3661-1550 email: eventos@mundopm.com.br

Patrocinadores:

Escritórios de Projetos: conceito geral

Por: Jackson Rovina

Os Escritórios de Gerenciamento de Projetos ou simplesmente Escritórios de Projeto se popularizaram no Brasil na última década, especialmente através de grandes empresas com alto volume de projetos ou das multinacionais trazendo conceitos de governança e práticas de gestão de suas sedes. Neste momento já podemos acompanhar exemplos de organizações de vários segmentos e portes, incluindo pequenas empresas buscando nos Escritórios de Projeto uma forma de se tornarem mais competitivas.

Escritório de Projetos é uma unidade organizacional criada para um crescimento mais rápido da competência de gerenciamento de projetos na organização, quando seus executivos percebem que podem aumentar as chances de sucesso dos projetos e que este aumento converte-se em resultados de negócios e aumento da competitividade da organização no mercado. A lista de benefícios é longa, então poderá resolver problemas diferentes a cada organização, podendo incluir a redução do tempo de lançamento de novos produtos, redução de custos, melhoria de clima organizacional, aderência a padrões globais de governança (corporativa e de Tecnologia da Informação), entre outros.

Em inglês é chamado de Project Management Office (PMO), ou somente Project Office, com variações de nomes, como no português. O Project Office é popular em países como os Estados Unidos ou Canadá até mesmo por ser um nome comum para o escritório do “canteiro de obras” em algumas construções, aquela casinha ou container para os engenheiros e gerentes de projeto que administram a obra. Aqui no Brasil isto acontece também, mas não é comum ser chamado de escritório de projetos, e por isto se torna um termo menos usual e mais difícil de assimilar.

O Guia PMBOK® do PMI® conceitua no seu glossário o PMO como “Um corpo ou entidade organizacional à qual são atribuídas várias responsabilidades relacionadas ao gerenciamento centralizado e coordenado dos projetos sob seu domínio. As responsabilidades de um PMO podem variar desde o fornecimento de funções de suporte ao gerenciamento de projetos até o gerenciamento direto de um projeto.”

Sendo normalmente uma unidade organizacional, é comum que um departamento, uma área, um setor ou mesmo uma assessoria seja criada e reconhecida por seus executivos e colaboradores. Algumas empresas atribuem à uma pessoa o nome de EGP ou PMO, algo no mínimo estranho. Esta pessoal poderá ser um analista de projetos, um gerente de projetos, programas, portfólio, mas dificilmente será um PMO se não for reconhecido como uma unidade organizacional distinta (e não somente uma pessoa distinta).

Mas... cada organização faz o que quer e chama como quer. O importante é que o escritório de projetos resolva problemas reais de negócio, condição clara para seu sucesso, continuidade e para o atendimento das expectativas dos envolvidos.

Certificados PMI-ACP

Após o período de piloto, o PMI divulgou números sobre a certificação PMI-ACP: São 515 profissionais certificados em todo mundo.

Este número é próximo a de outras certificações do PMI que já estão disponíveis a mais tempo como PgMP, PMI-RMP e PMI-SP, o que indica que a certificação ágil do PMI deve crescer muito em importância para os profissionais e empresas.

São 13 certificados no Brasil distribuídos da seguinte forma:

2 de MG

3 de SP

2 do RJ

2 do RS

2 do DF

1 do PR

1 de SC

Abaixo a distribuição das certificações pelo mundo:

USA 332

India 59

Canada 15

Brazil 13

Australia 8

Sweden 8

United Kingdom 8

China 7

Germany 6

Hong Kong 6

Singapore 6

Switzerland 6

Norway 5

Argentina 3

Unknown 3

Israel 2

Italy 2

Mexico 2

New Zealand 2

Paskistan 2

Portugal 2

South Africa 2

Spain 2

Turkey 2

Belgium 1

Bolivia 1

Bulgaria 1

Denmark 1

Egypt 1

Finland 1

Kuwait 1

Netherlands 1

Peru 1

Russian Federation 1

Saudi Arabia 1

Sri Lanka 1

Gestão Estratégica de Portfólio de Projetos e PMO

Caros Leitores,

Compartilho com vocês a oferta de um curso de pós-graduação muito interessante que será ministrado pelo SENAC São Paulo.

Formato: Presencial

Objetivo:

Capacitar profissionais para exercerem a função de executivo de projetos, para gerenciamento de múltiplos projetos envolvendo ambientes de alta competitividade e complexidade. Além disso, o curso aprimora conhecimentos e competências para tratar de forma integrada os aspectos projetuais estratégicos, orientados para gerar valor aos negócios da organização.

Público-alvo:

Profissionais da área de Gestão de Projetos, gerentes de portfólio de projetos, PMOs, gerentes de programas, gerentes de recursos, executivos e líderes de negócios, que buscam conhecimento para realização de um gerenciamento de projetos mais estratégico, que permita gerenciar a carteira de projetos como um investimento de negócios, medindo seus impactos nos resultados da organização, focando na seleção e priorização de projetos para maximização de seu valor, balanceá-lo adequadamente e alinhá-lo conforme a estratégia de qualquer empresa, independentemente de seu ramo de negócio.

Diferenciais:

O curso de pós-graduação em Gestão Estratégica de Portfólio de Projetos e PMO do Senac é inovador na abordagem dos temas mais avançados de conceitos, técnicas e práticas aplicadas no campo de gerenciamento de projetos, capacitando os profissionais em qualquer área de negócios para aplicarem as melhores práticas de gerenciamento projetuais preconizadas pelo Project Management Institute (PMI).

Nesse sentido, propõe uma formação diferenciada, tendo como base as diretrizes previstas na última edição do PMBOK® 2008 (4ª Edição do Guide to the Project Management Body of Knowledge) – framework desenvolvido pelo PMI para gerenciamento de projetos, e nas normas lançadas pelo PMI em 2008 - The Standard for Portfolio Management e The Standard for Program Management.

O Senac São Paulo figura ainda no roll reduzido de instituições que são, atualmente, reconhecidas e credenciadas pelo Project Management Institute(PMI) como Registered Education Provider (REP).

Carga horária: 366 horas

Para maiores informações: http://www.sp.senac.br/jsp/default.jsp?newsID=DYNAMIC,oracle.br.dataservers.CourseDataServer,selectCourse&course=14963&template=397.dwt&unit=NONE&testeira=724&type=P&sub=0

PMI São Paulo fecha parceria com a Produção Jr - UFSCar

Caros leitores,

É com imensa satisfação que anúncio que o PMI São Paulo firmou uma parceria com a Produção Jr, Empresa Junior da UFSCar (Universidade Federal de São Carlos).

Essa é mais uma iniciativa do PMI São Paulo em busca de aproximar suas ações com os estudantes, visando compartilhar conhecimento, incentivar a aplicação das boas práticas em gerenciamento de projetos e oferecer a oportunidade de conhecerem um pouco sobre a carreira em projetos.

Eu terei a honra e a oportunidade de ser o responsável pela gestão dessa parceria! No dia 04/02 eu farei a minha primeira visita à Produção Jr, em São Carlos.

Estou certo que será uma parceria duradoura e de muito sucesso! Realizaremos um grande trabalho juntos!!!

Conheçam um pouco mais sobre a Produção Jr visitando o site http://www.producaojr.dep.ufscar.br/

Seja um voluntário do PMI São Paulo

Se você está em busca de uma excelente oportunidade para desenvolver suas competências em gerenciamento de projetos e ampliar a sua rede de relacionamentos, venha fazer parte do time de voluntários do PMI São Paulo. 


Veja a oportunidade abaixo:

• Diretoria Responsável: Vice-Presidência
• Descrição: Gerenciar projetos ou programas nas áreas de Parcerias (Comerciais, Institucionais e Colaborativas) e Projetos na área de Responsabilidade Social. 
• Informações sobre Voluntariado: Vontade de aprender e colaborar com Gestão de Projetos, ligados às áreas de Parcerias e Responsabilidade Social.
• Disponibilidade Semanal: 4 a 6 hs semanais
• Prazo: Indeterminado.
• Pré-requisito: Ser associado do PMI São Paulo

Se estiver interessado, deixe o seu comentário com o seu e-mail para que eu possa entrar em contato.

Estudantes tem isenção da taxa de filiação ao Capítulo São Paulo

O Capítulo São Paulo do PMI passa a oferecer isenção da taxa de filiação para estudantes. Para se associar ao PMI, organização sem fins lucrativos fundada em 1969 e maior referência mundial em gerenciamento de projetos, é preciso primeiro filiar-se ao instituto, cuja sede fica na cidade de Filadélfia, e depois optar por filiar-se também a um ou mais capítulos disponíveis em todo o mundo. Todo o processo é realizado pela internet. A taxa da primeira filiação anual ao PMI para estudantes é de US$ 40 (para não-estudantes é de US$ 129). O custo da filiação ao Capítulo São Paulo do PMI era de US$ 20 anuais para estudantes e não estudantes mas, a partir de agora, estudante tem isenção da taxa. “Todos os estudantes tem direito a esse benefício, seja do ensino médio, graduação, MBA, pós-graduação, mestrado ou doutorado, desde que comprove estar matriculado regularmente”, afirma Milton Esteves, PMP, vice-presidente do Capítulo São Paulo do PMI e um dos responsáveis por essa iniciativa.

Mas por que fazer parte do PMI? Há muitos benefícios, tais como acesso gratuito a versão digital do Guia PMBOK®, descontos em eventos promovidos pelo PMI e por seus parceiros e descontos em certificações do PMI. O associado também usufrui de uma ampla base de conhecimentos. Isso inclui as comunidades de prática, que são espaços virtuais separados por área de interesse nos quais as pessoas compartilham suas experiências sobre determinado assunto, a biblioteca virtual eReads and Reference, com publicações completas sobre gerenciamento de projetos disponíveis para download, e muitas outras vantagens. Conheça todas elas acessando a página do PMI! “A filiação ao PMI demonstra seriedade, entusiasmo e dedicação em seu estágio ou trabalho em gerenciamento de projetos e garante acesso a todas as ferramentas e recursos disponíveis apenas para os membros do PMI”, diz Esteves. A associação a um capítulo próximo de você traz o gerenciamento de projetos para o dia-a-dia, com a garantia de qualidade e de boas práticas oferecidas pelo PMI. “Os membros do PMI filiam-se a um capítulo local para compartilhar seus interesses com colegas, aumentar sua rede de contatos profissionais, receber oportunidades de trabalho e aumentar o seu conhecimento através de atividades e serviços locais em sua cidade ou estado”, esclarece Esteves.

O gerenciamento de projetos hoje faz parte de praticamente qualquer ramo de atividade profissional; em todas as áreas existem projetos e o profissional capacitado para gerenciá-los ganha cada vez mais valor. “Hoje o assunto da moda é gerenciamento de projetos. Todas as empresas em todas as áreas estão se organizando para atingir as metas corporativas através de projetos, portanto, a filiação ao PMI e ao PMI São Paulo é interessante a todos os estudantes de todas as áreas”, avalia Esteves.

O Capítulo São Paulo do PMI já é um dos 12 maiores do mundo e pode crescer ainda mais com a sua filiação, trazendo com isso benefícios ainda maiores para a comunidade. “Nossa meta é atender as necessidades e expectativas dos nossos filiados, com informações que agreguem valor à profissão de Gerente de Projetos, e aproximando cada vez mais o Capítulo São Paulo do nosso associado. Claro que queremos crescer e nos tornar um dos maiores capítulos do mundo, quem sabe ficar entre os 5 maiores. mas buscando sempre a qualidade e agilidade na prestação dos serviços. Temos também trabalhado fortemente as parcerias com empresas junior, com o objetivo de aproximar o PMI dos estudantes e assim levar conhecimentos sobre as boas práticas de gestão de projetos à comunidade acadêmica”, diz Esteves.

Fonte: Site do PMI São Paulo (www.pmisp.org.br) 

Comparação avalia sistemas open source para gestão de projetos

Sistemas web e open source para gerenciamento de projetos oferecem soluções de qualidade, geralmente sem qualquer custo. Mais do que apenas organizar os projetos, elas podem incorporar todas as ferramentas necessárias de planejamento, organização, gerenciamento e elaboração de relatórios sobre recursos, para que você possa alcançar os objetivos do seu projeto.

Recursos web e open source para gerenciamento de projetos oferecem uma experiência única. Quando você compra softwares a maioria deles está compilado e pronto para ser usado. Você não pode fazer qualquer alteração no código do software. No código aberto é exatamente o oposto. Você obtém o programa compilado e tem também o código-fonte. Fica assim realmente encorajado a modificar o produto ou personalizá-lo da maneira que quiser. Para ser classificado como código aberto, o software deve atender aos seguintes critérios:

• O código fonte tem de ser incluído
• O programa pode ser distribuído gratuitamente
• Você pode redistribuir uma versão modificada
• Qualquer pessoa está autorizada a modificar o software
• A licença não pode exigir a exclusão de outros softwares

Quando se trata de software open source baseado na web para gestão de projetos há várias opções. Tudo que você precisa é uma conexão de internet e um navegador, com isso você pode acessar qualquer um dos programas que vamos apresentar. Não há necessidade de instalar qualquer software no seu computador. 

Você pode se surpreender ao saber algumas das maiores empresas do mundo realmente usam softwares open source baseados na web para gestão de projetos. Por quê? Porque isso significa que eles têm a capacidade de ajustar o software a qualquer tempo, a fim de apoiar a sua plataforma de negócios.

1. Redmine

Redmine é um banco de dados cruzado e multiplataforma. Ruby on Rails foi usado para escrever o Redmine, um programa de gestão de projetos flexível baseado na web que merece sua atenção. Ele inclui ainda gráficos de Gantt para que você possa ver facilmente onde seus projetos se encontram.

2. Codendi

Codendi incorpora todas as ferramentas necessárias que você precisa para gerenciar projetos, incluindo as equipes de desenvolvimento, suporte a bugs, documentos e ferramentas de relatórios de gestão.

  

3. Trac

Trac é mais do que um programa open source baseado na web para gestão de projetos. É também uma ferramenta de acompanhamento de bugs. É também uma interface web para sistemas como Git, Subversion, Darcs, Bazaar e Subversion.

  

4. ProjectPier

ProjectPier é livre, PHP auto-hospedado e uma aplicação de código aberto projetada para gerenciar projetos, equipes e tarefas usando uma interface intuitiva baseada na web. ProjectPier permite-lhe comunicar, organizar e colaborar - isso significa que você pode obter a funcionalidade que precisa.

5. eGroupWare

eGroupWare é um software open source baseado na web para gestão de projetos concebido para negócios de todos os tamanhos. Além de gerenciar seus projetos, você pode gerenciar compromissos, contatos e suas listas de tarefas. eGroupWare está disponível através de uma interface web ou com o uso de diferentes clientes de groupware suportados, tais como Novell Evolution, Outlook da Microsoft ou Kontact.

Gerenciamento de projetos com código aberto e baseado na web é uma alternativa que vale a pena considerar na sua busca do software ideal para gerenciamento de projetos.

Fonte: artigo publicado no site do PMI São Paulo: http://www.pmisp.org.br/noticias/compara%C3%A7%C3%A3o-avalia-sistemas-open-source-para-gest%C3%A3o-de-projetos