Características do Product Owner - Capacitado e comprometido

O Product Owner precisa ter autoridade suficiente e o nível certo de patrocínio da gerência para liderar o esforço de desenvolvimento e alinhar os stakeholders. Segundo Philip Missler, CEO da mobile.de, maior mercado de automóveis on-line da Alemanha, o gerente sênior seleciona este profissional, oferece suporte e atua como seu parceiro de jornada. Essa colaboração próxima permite que a equipe da gerência entenda melhor o progresso dos projetos individuais e cancele projetos malsucedidos desde cedo.

Fonte: Gestão de Produtos com Scrum, Roman Pichler, p. 6. Editora Campos.

Características do Product Owner - Comunicador e negociador

O Product Owner precisa ser um comunicador e negociador eficaz. Ele precisa alinhar-se e comunicar-se com diferentes parceiros, incluindo clientes, usuários, desenvolvimento e engenharia, marketing, vendas, serviço, operações e gerência; é a voz do cliente, comunicando suas necessidades e requisitos e unindo a lacuna entre os leigos e os técnicos. Às vezes, isso significa dizer não, e outras, negociar um meio-termo.

Fonte: Gestão de Produtos com Scrum, Roman Pichler, p. 6. Editora Campos.

Características do Product Owner - Visionário e Realizador

O escritor Jonathan Swift observou: "visão é a arte de ver coisas invisíveis". O Product Owner é um visionário que pode vislumbrar o produto final e comunicar essa visão. Ele também é um realizador que enxerga a visão inteira até o fim, o que inclui descrever requisitos, colaborar de perto com a equipe, aceitar ou rejeitar resultados de trabalho e dirigir o projeto, acompanhando e prevendo seu progresso. Como um empreendedor, o Product Owner facilita a criatividade, encoraja a inovação e sente-se bem com mudança, ambiguidade, debate, conflito, diversão, experimentação e exposição a riscos.

Fonte: Gestão de Produtos com Scrum, Roman Pichler, p.4. Editora Campos.

Características desejáveis do Product Owner

Escolher o Product Owner correto é crucial para qualquer projeto Scrum. Os Product Owners bem-sucedidos  com os quais trabalhei compartilham as características descritas a seguir. Como este é um papel novo, os indivíduos normalmente precisam de tempo e suporte para fazer a transição e adquirir as habilidades necessárias. Um desafio comum é encontrar funcionários com a amplitude e profundidade de conhecimento e experiência necessárias para bem realizar o trabalho.

Fonte: Gestão de Produtos com Scrum, Roman Pichler, p. 4. Editora Campos.

Gerência de projetos: barreiras à comunicação

Por Francisco Iglesias Bretas

A comunicação é o oxigênio das relações interpessoais. Proveniente do latim communicare, significa tornar comum, compartilhar idéias, elogios, críticas, sugestões, entre outros. Atualmente, os projetos alinham e encaminham o planejamento estratégico das organizações e, por isso, seu sucesso está diretamente relacionado à comunicação eficaz. É de suma importância que a comunicação obtenha um alto nível de compreensão e clareza em todas as suas formas e durante todo o projeto.

Uma comunicação eficaz ajuda a evitar surpresas durante a execução do projeto, antecipando situações desfavoráveis que podem ser encontradas ou, até mesmo, evitando o surgimento de barreiras à comunicação. Uma das formas de se reduzir essas barreiras é aplicar o processo de audição ativa, que faz com que o receptor esteja atento à mensagem transmitida, enviando sinais para o transmissor do seu entendimento ou não da mensagem. Estimular o transmissor para solicitar feedback, por meio de sinais ou parafraseando (repetindo suas próprias palavras), é uma das formas de tornar a comunicação mais eficiente.

No que se refere ao gerenciamento de projetos, uma das maneiras de se obter uma comunicação eficaz é organizar um Plano de Comunicação, cujo objetivo é o de descrever os processos de comunicação do cliente e a forma de administrá-los, para garantir que as informações cheguem às pessoas corretas, dentro do prazo necessário e de maneira economicamente viável, sendo constantemente atualizado. Dessa forma torna-se mais fácil identificar problemas com antecedência e, tão importante quanto, definir estratégias para solucioná-los, tornando o trabalho mais assertivo e aumentando a satisfação do cliente.

Mas como entender o significado da comunicação em projetos? Comunicar significa, entre outras coisas, trocar informações de tal forma que os interlocutores se compreendam. Na gestão de projetos, a comunicação faz com que as informações sigam um fluxo contínuo, de forma clara, até chegarem às pessoas capazes de tomar as decisões ou implantá-las. A gestão de projetos é uma realidade irreversível, que realmente traz uma série de benefícios para a produtividade, tanto na vida pessoal quanto profissional. Cada vez é mais comum ver organizações na busca constante pela maturidade em gestão de projetos, através do desenvolvimento de sistemas e processos que garantam uma alta probabilidade de sucesso nas suas operações. Mas quem ganha com isso? Os profissionais envolvidos? As organizações? Os colaboradores? Bom, de fato, todos ganham, porém, os mais beneficiados são os profissionais diretamente envolvidos e, é claro, as organizações e seus colaboradores, que assim conseguem atingir suas metas e garantir a “saúde” do negócio.

A comunicação é fundamental para integrar todas as partes envolvidas, mais comumente conhecidas como “Partes Interessadas” (do inglês stakeholders) e atender as expectativas de cada uma dessas partes no gerenciamento de um projeto.

De acordo com o Project Management Institute (PMI), 90% do trabalho de um Gerente de Projetos está ligado a atividades através da comunicação, pois ela é base e essência para o sucesso do Projeto. Além disso, o estudo de benchmarking em Gerenciamento de Projetos Brasil 2010 – Chapters Brasileiros mostra que 53,8% das Organizações que participaram do estudo confirmaram que a Comunicação é a habilidade mais deficiente em seus Gerentes de Projetos.

Atentos a todos esses aspectos, já é possível encontrar no mercado provedores de serviços que possibilitam uma melhor gestão de Projetos através do gerenciamento das comunicações, o que garante informações certas, para as pessoas certas, no tempo certo e de uma maneira economicamente viável.

Somente com uma melhor gestão da Comunicação é possível garantir a geração, coleta, distribuição, armazenamento, recuperação e destinação final das informações sobre o projeto de forma oportuna e adequada.

Sobre o autor: Francisco Iglesias Bretas é gerente de Projetos da Microcity, maior empresa brasileira de Outsourcing de Infraestrutura de TI

PMI São Paulo isenta estudantes de pagar taxa de filiação ao Capítulo!!!!

É com grande satisfação que compartilho com vocês essa novidade do PMI São Paulo: Isentar a taxa de filiação anual aos estudantes!!!

A partir de 18 de Janeiro de 2012 os estudantes que optarem pela filiação ou renovação ao PMI São Paulo não pagam mais a taxa de USD 20 anuais referente ao Capítulo, ou seja, custo zero para filiação ao PMI São Paulo. 

A única taxa que o estudante investe a partir de agora é:

Taxa de filiação anual ao PMI® EUA                    USD 30

Taxa referente à 1ª. filiação ao PMI® EUA.          USD 10

Total referente ao 1º. ano de filiação                USD 40

A partir do 2º. ano o estudante só investirá US 30 anuais no desenvolvimento de sua carreira em Gerenciamento de Projetos

Temos trabalhado fortemente as parcerias entre o PMI São Paulo e empresas Junior e identificamos um grande potencial nesta aproximação, principalmente com o desejo dos alunos em conhecer mais sobre o PMBoK, aplicar e melhorar os conceitos de Gestão de Projetos nas empresas Jr. e obter a certificação CAPM.

Estamos confiantes que a isenção na taxa de filiação dos estudantes ao PMI São Paulo em conjunto com estas parcerias institucionais, vão trazer bons frutos em futuro bem próximo.

Estudantes: Aproveitem esta oportunidade e se filiem ao PMI São Paulo o quanto antes. Agora é Grátis!

Para mais informações, visitem o site do PMI São Paulo www.pmisp.gov.br

Como organizar um Escritório de Projetos

Compartilho com vocês um artigo muito interessante e muito bem estruturado elaborado por Carlos Tristacci e publicado no site iMasters.com.br. Aproveitem!!!

Segundo o PMBOK, um escritório de projetos (PMO – Project Management Office) é um corpo ou entidade organizacional ao 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 fornecer funções de suporte ao gerenciamento de projetos até ser responsável pelo gerenciamento direto de um projeto. O PMO pode ser uma parte interessada se ele tiver responsabilidade direta ou indireta pelo resultado do projeto.

O PMO pode oferecer, mas não se limita a:

- Serviços de suporte administrativo, como políticas, metodologias e modelos;

- Treinamento, aconselhamento e orientação de gerentes de projeto;

- Suporte, orientação e treinamento em relação a como gerenciar projeto e usar ferramentas;

- Alinhamento de recursos humanos dos projetos e/ou

 - Comunicação centralizada entre gerentes de projetos, patrocinadores, gerentes e outras partes interessadas

Modelos de escritório de projetos

Segundo Mansur (2009), existem diversos modelos para o escritório de projetos. Em algumas empresas, o escritório de projetos é o responsável por todas as atividades referentes ao gerenciamento, administração e execução dos projetos.

No entanto, existem empresas que preferem que o escritório de projetos seja o responsável apenas pela consolidação das informações para uma visão geral de todos os projetos na organização.

Independentemente do modelo adotado, a implantação inicial do escritório do projeto deve ser realizada através de uma definição formal. A definição formal mostra de forma transparente o que a empresa entende como o papel e atribuições do escritório de projetos e quais são os motivos e expectativas para a sua implantação. Uma das grandes vantagens da transparência da definição do escritório de projetos é o controle das expectativas.

A definição formal típica do escritório apresenta a meta de obter ganhos de produtividade através do desenvolvimento e da implementação de uma estrutura de gerenciamento de projetos.

Ainda de acordo com Mansur, o gerenciamento das expectativas é habilitado pela comunicação e o pleno entendimento da definição formal e do processo de implantação do escritório de projetos por clientes, usuários e as principais partes interessadas.

Os quatro principais modelos do mercado da estrutura organizacional do escritório de projetos são:

- Escritório corporativo de projetos

- Escritório divisional de projetos

- Escritório setorial de projetos

- Escritório departamental de projetos

Escritório corporativo de projetos

O escritório de projetos está posicionado dentro da alta administração da organização, e os projetos são o desdobramento dos objetivos, as metas e os fatores críticos de sucesso do plano estratégico do negócio. Nesse caso, o Chefe do Escritório de Projetos (CPO – Chief Project Officer) deve ser um profissional experiente com ampla visão estratégica do negócio (MANSUR, 2009).

Escritório divisional de projetos

O escritório de projetos está posicionado dentro de uma divisão da organização, por exemplo, a diretoria de tecnologia. Nesse caso, responde ao diretor executivo de tecnologia (CTO – Chief Technology Officer) (MANSUR, 2009).

Escritório setorial de projetos

O escritório de projetos está posicionado dentro de um setor da organização, por exemplo, o setor de operações. Nesse caso, responde ao gerente de operações (COO – Chief Operating Officer) (MANSUR, 2009).

Escritório departamental de projetos

O escritório de projetos está posicionado dentro de um departamento da organização, por exemplo, o departamento de suporte de tecnologia, e nesse caso responde ao líder de suporte (MANSUR, 2009).

Referências

Project Management Institute (EUA). Um Guia do Conhecimento em Gerenciamento de Projetos: Guia PMBOK. 4. ed.  EUA: Mixed, 2008.

MANSUR, Ricardo. Escritório Avançado de Projetos: plano de negócio – a máquina de fazer dinheiro. Rio de Janeiro: Brasport, 2009.

O FATOR VDM — Um guia antidesastres em projetos criativos - para profissionais e clientes

Caros leitores,

Mais duas indicações de leitura. Nesse caso, o tema projeto é abordado com outra perspectiva, voltado ao pensamento criativo.

Ainda não os terminei de ler, porém, já recomendo mesmo assim. A leitura é muito agradável, leve e divertida, parece até que você está num bate-papo com o autor.

Segue uma breve resenha dos livros:

No ambiente dos serviços criativos, que envolve fornecedores, clientes, atendimento, veículos, públicos, orçamentos, cronogramas, reuniões e cafezinhos, é assim: para cada case de sucesso existem mil histórias onde o resultado final não ficou como esperado ou a relação saiu abalada. Merdas acontecem.


Portanto, se as coisas em algum momento deram errado não se martirize: você não está só. Mas também não se acomode. Existem formas de se prevenir dos desastres. Nos dois volumes da série O FATOR VDM, Luis Marcelo Mendes provoca gerentes de marketing,  designers, diretores de comunicação, desenvolvedores de sites,  cenógrafos, estudantes a entenderem que, na prática, fazer projetos não é fácil como parece. 

Esses guias, para profissionais criativos e clientes, mostram os caminhos para você estabelecer uma cultura projetual comum e produzir bons resultados.

Para saber mais, visite o site http://www.imaeditorial.com/ofatorvdm/

99º happy hour do PMI São Paulo

Participei do 99º happy hour do PMI São Paulo, realizado no Grill Hall, na região da Vila Mariana na cidade de São Paulo.

Tive a oportunidade de rever alguns amigos, fazer outros tantos novos e trocar algumas idéias com o ilustríssimo Professor Farhad.

Foi uma noite muito agradável com os colegas da comunidade do PMI São Paulo... o próximo happy hour será o CENTÉSIMO!!!! Um feito e tanto...

Não deixem de participar... eu estarei lá!!!

O Papel do Product Owner

O Product Owner lidera o esforço de desenvolvimento para criar um produto que gere os benefícios desejados. Isto frequentemente inclui criar a visão do produto; refinar o Product Backlog; planejar releases; envolver os clientes, usuários e outros stakeholders; gerenciar o budget; preparar o lançamento do produto; participar das reuniões do Scrum e colaborar com o time.

Por Roman Pichler em Gestão de Produtos com Scrum.

Livro: Gestão de Produtos com Scrum

Caros leitores,

Recomendo a vocês a leitura do livro "Gestão de Produtos com Scrum - Implementando métodos ágeis na criação e desenvolvimento de produtos", de autoria de Roman Pichler e editado pela Campus.

Transcrevo para vocês o texto da badana do livro:

Em Gestão de produtos com Scrum, o consultor Roman Pichler utiliza exemplos reais para demonstrar como os Product Owners podem criar produtos bem-sucedidos adotando as técnicas de gerenciamento ágil. Ele descreve diversas práticas, incluindo como fazer funcionar o trabalho de descoberta ágil do produto, tirar proveito de requisitos emergentes, criar o produto mínimo comercializável, aproveitar o feedback inicial do cliente e acompanhar de perto a equipe de desenvolvimento.

Com a vasta experiência de Pichler, você aprenderá como o controle sobre os processos de produtos utilizando o Scrum difere da gestão de produtos tradicional e como evitar e contornar os desafios comuns que os Product Owners enfrentam.

Este livro é uma ferramenta inédita e valiosa para qualquer gestor ou gerente de projeto que deseja ir um passo além e se tornar um Product Owner e começar a aplicar imediatamente os métodos ágeis em sua rotina de trabalho.

Sobre o autor:

Roman Pichler é um renomado especialista em Scrum e gestão ágil de produtos, com um longo currículo no ensino e treinamento de Product Owners e no auxílio às empresas que aplicam práticas eficazes de gestão de produtos. Como Certified Scrum Trainer, liderou a organização Scrum Alliance para desenvolver um currículo para o treinamento Certified Scrum Product Owner.

Hitler, Waterfall and Scrum

Uma colaboração da minha amiga Thais Guimarães... para descontrair!!!

Scrum Alliance's Certified Scrum Product Owner

Nos dias 19 e 20 de Janeiro, participei do treinamento "Scrum Alliance's Certified Scrum Product Owner" organizado pela Adaptworks e ministrado pelo instrutor Alexandre Magno.

Na formação para Product Owner os profissionais serão instruídos a pensar em sua gestão de uma forma ágil e criativa. Entendendo a fundo o dia-a-dia deste importante papel e conhecerão importantes ferramentas para auxiliar seu trabalho.

O treinamento foi excelente. Os conceitos do Scrum e do papel do Product Owner são passados de forma muito clara, objetiva e repleta de exemplos reais, o que ajuda o grupo a discutir situações e identificar comportamentos que dificultam a aplicação dos conceitos.

Além disso, durante o treinamento é feita a simulação prática do papel e das atividades de um PO, desde a definição de uma visão de produto, a identificação dos principais requisitos, o desenvolvimento do product backlog e do roadmap do projeto, até a priorização dos releases.

Recomendo o treinamento para todos os entusiastas das metodologias ágeis que buscam aprimorar e consolidar os seus conhecimentos nessa área.

Agora sou mais um Product Owner certificado pela Scrum Alliance!!!

Para mais informações, visite o site da Scrum Alliance: www.scrumalliance.com

PMBOK 5th Edition: contribua com a revisão dos standards do PMI

Compartilhe sua experiência profissional colaborando com a revisão dos standards do PMI! Os drafts das novas versões de The Standard for Portfolio Management – Third Edition, The Standard for Program Management – Third Edition e do PMBOK Guide – Fifth Edition são disponibilizados para revisão pública antes da publicação definitiva. Confira abaixo as datas disponíveis para revisar e comentar cada um deles:

• The Standard for Portfolio Management – Third Edition: até 14/01/2012
• The Standard for Program Management – Third Edition: de 06/02 a 06/03/2012
• PMBOK Guide – Fifth Edition: de 17/02/2012 a 20/03/2012

Além de contribuir com a construção do conhecimento em gerenciamento de projetos, você também tem acesso em primeira mão às novas versões dos standards do PMI. A revisão é feita através do próprio portal do PMI (basta ser um usuário registrado no site), que conta com uma ferramenta apropriada para facilitar o trabalho do revisor, com a possibilidade de marcar cada linha do texto que se pretende corrigir ou comentar. É proibido realizar qualquer tipo de cópia ou distribuição do material.

Todas as sugestões são avaliadas por um comitê decisório que se comunica por email com todos os candidatos a revisores.

Visite o site do PMI São Paulo (www.pmisp.org.br) ou do PMI Global (www.pmi.org) para obter mais informações.

Exposing the Myth of “Doing More With Less”

We first heard it in the early 00s–Executives and Managers saying, “We’ll just have to do more with less.” Well-intentioned at first, for some it soon became a poor alternative to managing effectively. While in specific situations the statement can be temporarily true, in most cases, we believe that those who proclaim and perpetuate the myth that this is an appropriate way to manage a workgroup, department or enterprise, are demonstrating their failure to manage.

What triggers this commentary is a recent workshop we performed for a customer we have worked with for over 22 years. We have seen them flex, grow, improve, and cut back, all in response to market conditions, the shape of their business, and their sense of coming business pressures. We did discuss the dangers of the “more with less” message with Executives and Managers 8 years ago, and with just a few exceptions, they have fortunately not fallen into that trap during this latest downturn. But in my recent sessions in this industry-leading business, we detected something sinister and terrifying.

While employees we encountered demonstrate strong loyalty to the organization, and show a sense of strong rapport up and down the chain of command, we detected individual contributors, project managers and managers alike who are overwhelmed and exhausted. People who have prided themselves on the quality and efficiency of their work in the past, are now deciding which essential project results will be eliminated or reduced; which project double-checks to push into post-project support; which internal customers to choose to fail to respond to. We have seen this death spiral before.

Jobless Recovery

Many organizations are facing this dilemma, in part because of the uncertainty in the US, between politics, consumer spending, the high unemployment rate, the threat of possible hyperinflation, and the unknowns in the next set of policy decisions that will affect business. These concerns are the root cause of this Jobless Recovery, as businesses are afraid to add staff to meet current demands, so they continue to manage increasing business with existing, or remaining staff. And even when they are not using the tired “more with less” mantra, that is what it looks like to their employees. And, if you think this only affects project success, this affects the operations side even more than the projects side of the business.

How To Honestly Do More With Less

In the early 2000s, as we starting hearing the “More With Less” mantra with increasing frequency, we put together a presentation, aimed at Managers and Executives, about “Doing More With Less.” In that presentation, we made a number of assertions, including that most managers who proclaim the need to do more with less were usually rewarded with much less with less. In other words, they were killing efficiency and effectiveness, overworking already exhausted team members, damaging morale more, negatively affecting the quality of the organization’s results more, and damaging the business unit’s or government agency’s reputation more. We’re not sure that is the more they were after.

We went on to coach Managers in the ways they really can do more with less. Interestingly (or not), the same Successful Project Climate guidelines we have recommended for years remain the best way to measurably do more with less—on a sustaining basis—and sustainability has been a recent theme in project management, so it makes sense to apply it to managing projects:

1. Prioritize better, then staff fewer current projects appropriately, completing each one better, faster and at lower cost, rather than fragmenting talent across too many projects.
2. Place team members full-time on large projects, at least half-time on medium ones (see The Successful Project Profile at the ProjectExperts website).
3. Eliminate project and ready response priority conflicts.
4. Eliminate, deflect or defer unnecessary interruptions in project work.
5. Position Managers to “carry the water” for the team, pushing barriers out of the way, and demonstrating that the organization works for the team, rather than vice-versa.
6. Measure and manage both effort and results, and recognize and reward achievements.

Nothing more than competent Managers of Project Managers and their teams have done all along, but these actions are even more important in difficult times. Most practitioners understand that while teams could perhaps, at peak, produce 10%-20% more results, Managers, internal Customers and Executives have the power to improve performance by 2x–4x in individual projects, and 8x—10x in the overall organization over a 3-5 year period. Now that is an honest and measurable way of Doing More With Less.

By Stacy Goff, IPMA VP of Marketing & Events (http://ip-ma.com/2011/exposing-the-myth/)

PMI Code of Ethics and Professional Conduct

Don’t steal, don’t cheat, and don’t lie. This short sentence pretty much sums up the PMI Code of Ethics and Professional Conduct (the Code). It describes the expectations that we have of ourselves and our fellow practitioners in the global project management community. It articulates the ideals to which we aspire as well as the behaviors that are mandatory in our professional and volunteer roles. The purpose of the Code is to instill confidence in the project management profession and to help an individual become a better practitioner.

The Code is not contained within the PMBOK® Guide. Instead, it is part of the PMP Credentials Handbook available at http://www.pmi.org/Certification/~/media/PDF/Certifications/pdc_pmphandbook.ashx. Just like the PMBOK® Guide, this is a "must read" for anyone studying to take the PMP® or CAPM® exam. Unlike the PMBOK Guide, where memorization is necessary to pass the exam, you will not be asked to recite from the Code during the exam. Instead, expect several scenario-based questions where you have to show that you can apply the Code. For example, "You have just arrived in London where you will spend three days with a vendor reviewing a proposal. The vendor calls you in your hotel room and invites you to dinner. What do you do?"

Let's take a look into this important document. Upon creating the code, the PMI found that there are four values project managers around the globe identified as being important: responsibility, respect, fairness, and honesty. These values have become the foundation of the Code and each of them is discussed at length in a separate section. For each of these values the Code lists aspirational and mandatory standards. The aspirational standards describe the conduct that we strive to uphold as practitioners. Although adherence to the aspirational standards is not easily measured, conducting ourselves in accordance with these is an expectation that we have of ourselves. The mandatory standards establish firm requirements, and in some cases, limit or prohibit practitioner behavior.

Practitioners who do not conduct themselves in accordance with these standards will be subject to disciplinary procedures before PMI’s Ethics Review Committee. However, even though we have this distinction of aspirational and mandatory standards, consider everything in the Code as mandatory for the PMP exam. The code applies to you both as a PMP Aspirant and later on also as a PMP. First, as a PMP Aspirant, when you apply for the PMP Exam you will be asked to sign the PMP Candidate Agreement and Release form. In it you state that as a PMP Aspirant you will comply with the Code. This means, for instance, that you don’t cheat on the PMP exam.

Once you pass the exam the code also applies to you as a PMP. Now you should exercise Responsibility and take ownership of the decisions you make or fail to make; show Respect to yourself, others, and the resources entrusted to you; apply Fairness when making decisions and act impartially and objectively; and finally, employ Honesty in both your communication and conduct. If we all manage to live up to these high standards from the Code we will improve the respect others have towards our profession as well as enrich today’s business world. 

Here are two more examples of applying the value of Honesty to your work: First, as a project manager, you may be working on-site for your client and you may have access to proprietary and copyrighted material or information. The confidentiality of intellectual property that you have access to must be maintained. And second, let's look at status reports or press releases that you provide. The information that you as a PMP provide in these documents must be accurate and truthful regardless how difficult it may be to define the word “truth.”

Applying the Code in your daily dealings with work colleagues and your colleagues in the professional organizations will also set you apart. The Code can assist you in making wise decisions, especially when you are faced with difficult situations when you might be asked to compromise your integrity and values. Sticking to the Code will show others that you are an upstanding, ethical project manager.

To take this a step further — if your colleagues know this is how you operate, this will become a valuable part of your reputation. Being honest and ethical makes finding a new job much easier than if you had the reputation of stealing, backstabbing, and lying.

Let's come back to that dinner invitation example from earlier. Would you accept or would you decline? I would accept because going out to dinner with a vendor or partner is normal social behavior and will not jeopardize your objectivity on the project. However, if the vendor offers a free Caribbean cruise to you then you should decline and notify your superiors.

Next to the PMBOK Guide, the PMI Code of Ethics and Professional Conduct is one of the more important documents covered on the exam. This is why we have a whole episode of the PrepCast dedicated to explaining the Code to you. We give you real life examples of how it applies to your work on a project and what you should do in a given situation.

Fonte: PM PrepCast (http://www.project-management-prepcast.com/index.php/freetry-it/tips-a-articles/71-pmi-code-of-ethics-and-professional-conduct)

IPMA Brasil participa do Programa IPMA V 4.0

Na busca de levar o Brasil cada vez mais próximo da excelência em Gestão de Projetos, grupo do IPMA-Brasil  representado por seu Presidente Raphael Albergarias e composto por Luciano Kolotelo, Luiz Rocha, Wilson Guilherme esteve presente nos encontros de revisão de todos os referenciais de Competência da IPMA.

Neste último encontro em Dublin, em Setembro 2011, contou com a presença de Raphael Albergarias e Luiz Rocha que representaram o Brasil numa esfera de discussão que visa a elevação da ciência de Gestão de Projetos Global, com a redefinição do que é competência. Com uma participação ativa em todos os fóruns promovidos pelo IPMA estes brasileiros tem um único objetivo: contribuir para um salto qualitativo na Gestão de Projetos no Brasil e no Mundo.

O programa IPMA V 4.0 é composto pelo projeto de revisão do ICB (IPMA Competence Baseline) e do ICRG (IPMA Certification Regulations and Guidelines), no qual  atualmente 20 países participam. É uma contribuição da Gestão de Projetos do Brasil para o mundo!

Five Lessons from World Changers

Now is the time to change the world. The past decade has been one of remarkable transformation and seemingly endless crisis. We've seen hundreds of millions rise from poverty to the ranks of the middle class, but we face persistent and difficult problems like disease, economic recession, and financial turmoil. Correspondingly, we need leaders who are willing to address those challenges.

They exist. The Passion & Purpose MBA survey found that, among graduate business students at least, two of the top three reasons for choosing a workplace were "intellectual challenge" and "opportunity to impact the world," and nearly 85% of those surveyed thought "business people are well-qualified to solve the most pressing problems in the world."

But what would it take for us, as individuals, to be world changers? That's the central question in John Byrne's new book, World Changers.* In it, Byrne recounts discussions with 25 entrepreneurs who have changed the world — people like Oprah Winfrey, Bill Gates, and Richard Branson. Byrne focuses on allowing those people to tell their stories, but in reading them, I found several valuable lessons for world changers in the making.

1. Start with purpose: Perhaps the greatest common denominator amongst great world changers is the centrality of purpose in their organizations. Google's mission is to "to organize the world's information and make it universally accessible and useful." Whole Foods' motto is "Whole Foods, Whole People, Whole Planet." And Facebook's mission is "to give people the power to share and make the world more open and connected." This purpose is what serves as a compass for the company and its employees. Finding and articulating your purpose are critical to launching a world-changing enterprise.

2. You're not too old: Too often, we view entrepreneurship as a young person's game or something for which you must be uniquely suited. Rather, entrepreneurship is about having an idea and the courage to pursue it — no matter your age. Did you know that when Bernie Marcus and Arthur Blank started Home Depot, they were 34 and 48 years old, respectively? Further, neither was an entrepreneur: Marcus was a former pharmacist, and both had just been fired from their jobs at Handy Dan Improvement Centers.

3. Seek advice: It's difficult to start and grow a company in isolation, and mentorship and peer counseling are critical to maintaining your focus and direction. Find those who have been through your experience before and seek their guidance on the situation. Even great entrepreneurs like Howard Schultz seek advice when confronted with difficult situations. Schultz reassumed his leadership post at Starbucks, at least partially, as a result of a bicycle ride with Michael Dell. Schultz and Dell ran into each other vacationing in Hawaii, and during a three-hour ride along the Kona coast, Dell advised Schultz on how to handle Wall Street and the company if he resumed leadership at then struggling Starbucks.

4. Be the expert: Many MBAs, in particular, are tempted to launch businesses they know little about because they seem to have big "upside" — but to change the world it pays to be an expert. Find something you love, become an expert, and see what it would take to innovate in the space. Larry Page and Sergey Brin succeeded at Google at least partially because they were experts on search. To quote Page: "[W]e really benefited from being real experts...we understood all aspects of search. We talked to all the search companies. We really knew a lot about what was going on." They didn't know exactly how to bring their product to market or build a world-class organization, but they knew more about how to comb the web for useful information than anyone on the planet.

5. Start small: World-changing businesses are rarely world-changing from day one. Sometimes they're not even fully formed concepts. Many groundbreaking entrepreneurs simply start with a small idea and grow with it as the idea evolves. If you're waiting to launch your business because you can't see the path to changing the world, you may be missing an opportunity to learn through experimentation. One of the most shocking lessons of World Changers was how few of these entrepreneurs started "big" or even with "big things" in mind. Oprah Winfrey launched her career as a TV reporter in Nashville and worked as a reporter of local talk show host until entertainment lawyer Jeff Jacobs encouraged her to create her own show and company. Richard Branson sold records out of the trunk of his car, and Michael Dell got into business for himself, upgrading personal computers from his college dorm room.

It's a new year with new opportunities. Learning these five lessons is the first step to making an impact. How will you change the world?

Artigo redigido por John Coleman e publicado no blog da Harvard Business Review (http://blogs.hbr.org/cs/2012/01/five_lessons_from_world_changers.html)

Governança de Riscos

Por: Mario Trentim

Gerenciamento de Riscos é um dos assuntos mais quentes do momento. Não apenas por causa da crise econômico-financeira mundial que vem se estendendo desde 2008, mas também do ponto de vista do gerenciamento de projetos, programas e portfólio.

Podemos separar os riscos de um projeto, simplificadamente, em duas categorias:

• Execução: riscos relacionados ao gerenciamento do projeto durante o seu ciclo de vida.
• Resultado: riscos relacionados ao resultado do projeto.

Os riscos de gerenciamento do projeto são nossos velhos conhecidos: atraso, qualidade, gastos, comunicação e outros. Embora conhecidos, não são tratados adequadamente. Pesquisas apontam que 90% dos GPs subestimam o tamanho ou a complexidade dos projetos que gerenciam [Robbins-Gioia, 1999]. 

Consequentemente, a capacidade gerencial e de execução precisa ser analisada:

• O planejamento é adequado?
• As estimativas são confiáveis?
• Os riscos associados aos pacotes de trabalho, tarefas, recursos e outros aspectos do projeto foram identificados e analisados?
• Somos capazes de executar o projeto? (Competência Técnica)

Não bastando os riscos de (ou falta de) gerenciamento do projeto, existem ainda os riscos inerentes ao resultado exclusivo, produto ou serviço. Todo projeto e seu resultado devem ter seus riscos analisados do ponto de vista do negócio. Ou seja, deve-se responder às seguintes perguntas:

• Se o projeto ou produto falharem, minha empresa (negócio) será prejudicado? Em caso positivo, qual o impacto?
• Se o projeto ou produto falharem, é possível corrigir?
• Minha empresa sobreviverá? Qual o tempo necessário para reverter?

Portanto, não basta apenas identificar, analisar e responder aos riscos técnico-gerenciais internos ao projeto. Essa abordagem míope leva ao chamado ótimo-local, isto é, o ponto ótimo do ponto de vista interno do projeto. É isso que os gerentes de projeto comumente buscam. Porém, o ótimo-local pode não ser, e na maioria das vezes não é, o ponto ótimo-global.

Sem entrar nas minúcias matemáticas, a soma de ótimos-locais não resulta em um ótimo-global. Desta forma, quando os gerentes de projetos procuram maximizar os resultados de seus projetos, podem estar destruindo, não adicionando, valor ao negócio. Ou seja, algumas abordagens de gerenciamento dos riscos criam mais riscos [Matts & Maassen, 2011].

A solução para o referido problema é a governança. Em nossa discussão sobre gerenciamento de riscos, precisamos de uma governança de riscos. Embora o PMI estabeleça o termo governança de riscos em The Practice Standard for Risk Management, não se trata de um padrão completo. Existem outros padrões variados e alguns específicos para determinadas áreas, tais como ISO 31000 e COSO.

A governança corporativa de riscos compreende ainda:

• identificar padrões e políticas de gerenciamento de riscos;
• padronizar políticas e práticas de gerenciamento de riscos;
• criar métricas para medir a performance do gerenciamento de riscos;
• monitorar os resultados do gerenciamento de riscos; e,
• documentar lições aprendidas e realizar melhoria contínua dos processos.

Concluímos que os gerentes de projetos, bem como os gestores de programas, portfólio e PMO, devem analisar detalhadamente o risco para o negócio trazido pelo projeto. Este risco deve ser entendido do ponto de visto corporativo e do modelo de negócio. Devemos, então, avançar do gerenciamento de riscos interno aos projetos para uma abordagem corporativa.

Fonte: Blog da Revista Mundo PM (http://blog.mundopm.com.br/category/boas-praticas-2/)

GP e o sucesso das organizações

O Gerenciamento de Projetos ajuda as organizações a atenderem as necessidades de seus clientes padronizando tarefas rotineiras e reduzindo o número daquelas que poderiam ser esquecidas. O Gerenciamento de Projetos assegura que os recursos disponíveis são alocados da maneira mais eficiente e eficaz, permitindo aos executivos seniores a perceber “o que está acontecendo” e “para onde as coisas estão indo” dentro das organizações.

Muitas organizações ao redor do mundo, como NASA, IBM, AT&T, Siemens, Chiyoda Corporation, PricewaterhouseCoopers, Sociedade Computacional de Singapura e o Governo Estadual de Oregon (EUA), lançam mão do Gerenciamento de Projetos para desenvolver processos inovadores, planejar, organizar e controlar iniciativas estratégicas, monitorar desempenho de empreendimentos, analisar divergências significantes e prever seus impactos nos projeto e na organização.

A aplicação dos princípios de Gerenciamento de Projetos permite que os executivos seniores:

• Estabeleçam medidas do sucesso
• Mantenham o foco no cliente
• Quantifiquem o valor agregado correspondente aos custos
• Aperfeiçoem o uso dos recursos da organização
• Incorporem princípios de qualidade
• Coloquem planos estratégicos em marcha
• Assegurar a atualização da empresa às demandas do mercado

O Gerenciamento de Projetos ganhou popularidade durante as últimas décadas em função de uma série de mudanças significativas no local de trabalho. Algumas destas mudanças incluem:

• Processos de Downsizing (menos pessoas para fazer mais tarefas)
• Projetos e serviços maiores e mais complexos
• Competição global e feroz
• Acesso à informação mais fácil através de amplas redes de comunicação
• Clientes mais sofisticados que exigem produtos e serviços de maior qualidade
• Crescimento tecnológico exponencial
• Organizações multinacionais que buscam estabelecer práticas uniformes para gerenciar projetos

O Gerenciamento de Projetos está sendo aplicado em muitas indústrias hoje, da construção e sistemas de informação para assistência médica, serviços financeiros, educação e treinamento. Com esta expansão, as pessoas que dirigem projetos atualmente têm diferentes formações profissionais e acadêmicas, e trazem diferentes níveis de experiência como praticantes do Gerenciamento de Projetos. Para se prepararem para os papéis de gerente de projeto ou de integrante de equipes de projeto, os indivíduos devem assimilar uma compreensão básica dos processos e das áreas de conhecimento que são comuns a todos os projetos.

Fonte: Artigo publico no site do Capítulo PMI de Santa Catarina (http://www.pmisc.org.br/open.php?pk=46&id_ses=4)

Metodologias ágeis, tendências e opções

Por: Deodato Santos Cunha

O tema “Gestão de Projetos” é cada vez mais comentado nas empresas, a necessidade por uma gestão eficiente, estruturada e clara é crescente. Atualmente uma das palavras de ordem é “eficiência”. Eficiência é a capacidade de uma empresa/organização conseguir manter sua operação, com qualidade, e apenas com os recursos necessários. No artigo deste mês vamos falar sobre as duas principais metodologias ágeis existentes e suas aplicabilidades para apoiar tal gestão.

Para introduzir o assunto, segue abaixo o manifesto ágil, publicado em 2001:

“Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazerem o mesmo. Através deste trabalho, passamos a valorizar:

• Indivíduos e interações mais que processos e ferramentas
• Software em funcionamento mais que documentação abrangente
• Colaboração com o cliente mais que negociação de contratos
• Responder a mudanças mais que seguir um plano

Continuando, vou descrever sucintamente os dois métodos ágeis mais conhecidos na área de desenvolvimento de software:

SCRUM

O Scrum é um processo de desenvolvimento iterativo, dinâmico e incremental para gerenciamento de projetos e desenvolvimento ágil de software. Scrum não é um processo prescritivo, ou seja, ele não descreve o que fazer em cada situação. Ele é usado para trabalhos complexos nos quais é difícil antecipar o planejamento, entregas do projeto ou os riscos do projeto. Apesar do Scrum ter sido destinado para gerenciamento de projetos de software, ele pode ser utilizado em uma abordagem geral de gerenciamento de projetos/programas.

Scrum é um framework que contém um conjunto de práticas e papéis pré-definidos. Os principais papéis são: o ScrumMaster, que mantém os processos (normalmente no lugar de um gerente de projeto), o Proprietário do Produto, ou Product Owner, que representa os stakeholders , o negócio e a equipe que é um grupo multifuncional que faz a análise, projeto, implementação e testes. 

Na prática o Scrum funciona da seguinte maneira, cria-se um product backlog que é uma lista de itens priorizados que precisam ser desenvolvidos (lista de requisitos). O product backlog é mantido pelo product owner, depois  cria-se o sprint backlog que é o detalhamento dos requisitos contidos no product backlog ao ponto de ser a referência do time de desenvolvimento. Após isso, é feito o planejamento do sprint (execução/desenvolvimento dos itens que estão no sprint backlog ),durante o sprint  ocorrem reuniões diárias, chamadas Daily Scrum, essas reuniões podem ocorrer no período da manhã, e são discutidas as tarefas executadas no dia anterior e as atividades do dia, recomenda-se que esta reunião dure no máximo 15 minutos.

eXtreme Programming ou XP

Programação extrema (do inglês eXtreme Programming), ou simplesmente XP, é uma metodologia ágil mais indicada para equipes pequenas e médias que irão desenvolver software com requisitos vagos e em constante mudança. Para isso, adota a estratégia de constante acompanhamento e realização de vários pequenos ajustes durante o desenvolvimento de software. Os cinco valores fundamentais da metodologia XP são: comunicação, simplicidade, feedback, coragem e respeito. A partir desses valores, possui como princípios básicos: feedback rápido, presumir simplicidade, mudanças incrementais, abraçar mudanças e trabalho de qualidade.

Dentre as variáveis de controle em projetos (custo, tempo, qualidade e escopo), há um foco explícito em escopo. Para isso, recomenda-se a priorização de funcionalidades que representem maior valor agregado possível para o negócio. Desta forma, caso seja necessário a diminuição de escopo, as funcionalidades menos valiosas serão adiadas ou canceladas.

A XP incentiva o controle da qualidade como variável do projeto, pois o ganho de curto prazo na produtividade, ao diminuir a qualidade, não é compensado por perdas (ou até impedimentos) a médio e longo prazo.

Concluindo, percebemos que os métodos ágeis estão sendo disseminados e cada vez mais empresas estão adotando. Como disse no começo do artigo, as empresas estão buscando eficiência, e os métodos ágeis buscam contribuir para esse aspecto.

Fonte: Publicado na e-News do PMI São Paulo em Junho de 2011.

Diferenciando Programas de Projetos

Por Clay Susini Aquino Junior, PMP

Um equívoco comum cometido pelos Escritórios de Gerenciamento de Projetos é conceber um Programa como Projeto ou vice e versa.

Em um primeiro momento esse tema parece soar sem importância, como se fosse apenas mais uma definição teórica e puramente conceitual, mas é a base para o fracasso real de inúmeros Projetos.

No Brasil e, principalmente, no setor corporativo privado, Projetos são erroneamente definidos como Programas apenas por serem grandes. Mas o tamanho é simplesmente a consequência, e não o motivo para um Programa existir.

Outras justificativas usadas para transformar conjuntos de Projetos em Programa são o aproveitamento da dinâmica comum de vários recursos e a existência de inúmeras frentes de trabalho com mais de um time. Realmente Programas possuem essas características, mas apenas como consequência de um fator maior: a concepção de uma idéia geradora de um benefício estratégico, dando origem a um conjunto de iniciativas independentes responsáveis por concretizar o benefício idealizado.

Um Programa, antes de se tornar um conjunto de projetos, nasce como uma idéia estratégica geradora de um benefício singular, sem a real certeza de que virá a se tornar dois, cinco ou dezenas de Projetos independentes. No momento de concepção do Programa, não sabemos ao certo o que deve ser feito para atingir o benefício idealizado, tampouco como fazer. Sabemos apenas que uma série de tarefas independentes gerará um benefício estratégico e único. E é comum um Programa, em plena execução, ainda gerar novos Projetos com o intuito de consolidar o benefício estratégico definido anteriormente.

Por sua vez, Projeto é um esforço pontual, menos abstrato. Por mais que um Projeto em sua fase de iniciação possua indefinição de escopo, tempo e custo, sempre temos em mente a principal entrega. Sabemos o “o que”. Apenas não sabemos ainda o “como”. E nesse contexto, para diferenciar um Projeto de um Programa, não importa o tempo, o custo e nem a quantidade ou interação entre os recursos.

Parafraseando o PMBoK (Project Management Body of Knowledge), do PMI (Project Management Institute), Projeto é um empreendimento temporário, com recursos limitados, que gera um resultado, produto ou serviço único. Já Programa é um conjunto de Projetos independentes que estão unidos e associados estrategicamente para geração de um benefício. Em um Programa, obviamente cada projeto possui um benefício próprio, afinal são independentes. Mas o benefício gerado pelo Programa é diferente dos benefícios individuais de cada Projeto. E esse benefício do Programa é geralmente pensado primeiramente e estrategicamente antes de ser criado o conjunto de Projetos.

Como exemplo, podemos citar o Programa de Aceleração do Crescimento (PAC) do Governo Federal. O Programa possui como objetivo construir infraestrutura logística e energética para sustentar o crescimento do País. O objetivo de um Programa sempre terá a característica de ser abstrato, pois na concepção da idéia só há a expectativa do benefício e não do objeto entrega. Não sabemos exatamente o que terá que ser feito para que o benefício seja obtido, tampouco como.

O Governo Federal dividiu o PAC em seis Subprogramas e duas Frentes de Trabalho. Os Subprogramas do PAC são: PAC Energia, PAC Habitação, PAC Cidade Melhor, PAC Comunidade Cidadã, PAC Água e Luz Para Todos e PAC Transportes.

Cada um desses Subprogramas possui vários Projetos. Por exemplo, o Subprograma Cidade Melhor possui o Projeto Construção Estação de Tratamento de Esgoto na Baixada Santista, o Projeto de Construção de Drenagem Urbana na Baixada Fluminense, entre outros. E há também os Projetos internos do Programa que não são expostos à população, como Projetos de marketing para promover o Programa em rádio, TV e Internet, Projetos de Desenvolvimento de Sistemas de Informação do Governo etc.

Outra característica dos Programas é a existência das Frentes de Trabalho. Em tradução livre do The Standard for Program Management do PMI, Programas incluem elementos de trabalho não contidos em nenhum de seus Projetos. Esses elementos são as Frentes de Trabalho, que atravessam os Projetos, não necessariamente todos, apoiando a integração necessária para o benefício único do Programa. Como exemplo, a auditoria interna poderia ser uma Frente de Trabalho do PAC. As ações de auditoria atravessariam os Projetos gerando o benefício de integridade do Programa como um todo. Mas oficialmente o PAC possui duas Frentes de Trabalho: Medidas Institucionais e econômicas e a outra é Desenvolvimento Econômico Social.

A construção de uma usina hidrelétrica, por exemplo, se idealizada unitariamente, é um Projeto. Mesmo que demore 10 anos para ser construída e mobilize bilhões de reais, continuaria sendo um Projeto, e não um Programa, pois o que foi idealizado é o produto de forma direta.

Essa usina poderia estar dentro do Programa de Aceleração do Crescimento, e seria completamente normal caso a usina não tivesse sido idealizada no momento da concepção do Programa, pois se pensou no benefício da Aceleração do Crescimento no Brasil, e não em todas as entregas palpáveis que concretizariam esse benefício.

Programas geralmente possuem fases futuras totalmente abstratas em escopo, tempo e custo, muito mais abstratas que as fases futuras de um Projeto. De maneira rotineira, Programas são subdivididos em fases ou subprogramas. A primeira fase constantemente possui projetos visualizados com mais clareza ou já em execução. E a as demais com a visualização apenas da percepção do benefício desejado.

Após toda essa exposição conceitual, ainda perdura a dúvida: qual o problema em confundir Projeto com Programa ou vice e versa?

Conceber e executar um Projeto como Programa não é tão grave, mas certamente criará na corporação uma imagem errada do que é Programa e a sensação de que gerenciar Programa é o mesmo que gerenciar Projeto. E caso a corporação comece a implementar o conceito de Programa, terá dificuldade em difundir o conceito correto.

Porém, será catastrófico executar um Projeto quando na verdade for um Programa. O “Projeto” sofrerá aumento de escopo e prazo constantemente e a corporação não entenderá o motivo, mas ocorre que o peso de uma idéia estratégica, que é abstrata, foi delineado para ser entregue em um único “Projeto”, que possui um molde pontual e bem mais objetivo que a fase inicial de um Programa. O titulado “Projeto” nesse caso, terá inúmeras fases e mais cedo ou mais tarde essas serão tão independentes uma das outras que possuirão entregas totalmente diferentes, autossuficientes e com objetivos próprios. Novas entregas começarão a ser criadas no decorrer do ciclo de vida e não serão bem aceitos pela corporação, pois serão concebidas como se fossem incrementos de escopo (scope creep) e causadoras de atraso, quando na verdade são novos Projetos, independentes, e que apenas agora se visualizou a necessidade estratégica de criá-los e assim solidificar cada vez mais a expectativa abstrata inicial. Essa sucessão de desastres costuma ocorrer quando se faz a gestão de um Projeto sendo na verdade um Programa.

Texto publicado na e-News do PMI São Paulo de dezembro de 2011

Sobre o autor: Clay Susini Aquino Junior é Gerente de Programas e Projetos da BM&FBOVESPA, certificado Project Management Professional (PMP), MBA em Gerenciamento de Projetos pela Fundação Getúlio Vargas, Bacharel em Sistemas de Informação com Ênfase em Planejamento Estratégico pela Universidade Presbiteriana Mackenzie, membro do PMI (Project Management Institute) e do IFPUG (International Function Point Users Group).

PMBOK 5th Edition: contribua com a revisão dos standards do PMI

Compartilhe sua experiência profissional colaborando com a revisão dos standards do PMI! Os drafts das novas versões de The Standard for Portfolio Management – Third Edition, The Standard for Program Management – Third Edition e do PMBOK Guide – Fifth Edition são disponibilizados para revisão pública antes da publicação definitiva. Confira abaixo as datas disponíveis para revisar e comentar cada um deles:

• The Standard for Portfolio Management – Third Edition: até 14/01/2012
• The Standard for Program Management – Third Edition: de 06/02 a 06/03/2012
• PMBOK Guide – Fifth Edition: de 17/02/2012 a 20/03/2012

Além de contribuir com a construção do conhecimento em gerenciamento de projetos, você também tem acesso em primeira mão às novas versões dos standards do PMI. A revisão é feita através do próprio portal do PMI (basta ser um usuário registrado no site), que conta com uma ferramenta apropriada para facilitar o trabalho do revisor, com a possibilidade de marcar cada linha do texto que se pretende corrigir ou comentar. É proibido realizar qualquer tipo de cópia ou distribuição do material.

Todas as sugestões são avaliadas por um comitê decisório que se comunica por email com todos os candidatos a revisores.

Fonte: Site PMI São Paulo.